What happens when an exception kills a Windows CE process? RRS feed

  • Question

  • I want to know what happens under special conditions, when a Windows CE 5.0 process dies due to an exception. Please let me describe the setup.

    The process has at least two threads. One thread calls a driver. The driver has a synchronization object (critical section) and the calling thread waits with an EnterCriticalSection. The thread has already locked other resources, e.g. has entered other critical sections or has handles to allocated resources.

    When the other thread causes an exception (access violation, division by zero) or is killed, what happens to the ressources that is currently owned by the thread in the driver? Is the critical section left? Are other handles closed? How are heap objects handled that have been temporarily allocated by the thread in the driver?

    Since the exception occurs not in the thread in the driver, it should not be possible to do any exception handling in the driver, should it?

    Wednesday, April 25, 2012 6:30 AM

All replies

  • Any process are the child of any parent process or atleast the init process.

    When a child process dies (due to what ever reason) the parent process will invoke the resource cleanup of the child process. The child will then be zombic and will remain till it is removed from the process table.

    When a parent process dies, the child will be adopted by the init process  and resource cleanup will be done by it.

    yes it is possiable to do exception handling in the driver as well.

    Hope i have answered your question.

    --- Misbah

    Senior Design Engineer T.E.S Electroni Solutions (Bangalore-India)

    Thursday, April 26, 2012 7:37 AM
  • Misbah, thanks for reply.

    The driver is hosted in the process device.exe. The thread originates from any other client process. I don't see any parentship between these two processes. What do you refere as the "init process"?

    > yes it is possiable to do exception handling in the driver as well.
    Which kind of exception is thrown when the client process dies? How can I catch this exception?

    > Hope i have answered your question.
    Unfortunately I did not find the answer.


    Thursday, April 26, 2012 7:51 AM
  • Driver is a dll loaded by the device manager under the address apace of device.exe process. NK.exe is the parent of device.exe. There are several process spawned by NK.exe hence it will be the parent of these. You can call this as init (Unix based name)

    Which thread are you referring to ? if a thread is created under a process it will run under the address space of that process.  i.e if a thread is created under the driver it will run under the address space of the driver being loaded to, similarly if a user space application creates a thread the thread will run under user space address space and have access to the resource of it.

    When an application access the driver, there is a context switch from user mode to kernel mode and back to user mode, momentarily execution occurs in the kernel context.

    If an exception occurs it will be either in kernel context or user context, if an exception is occurred in the driver device manager will unload the driver. 

    Similarly if an exception has occurred in the user program execution of it will get stopped. There is no way that it will effect the driver it is accessing except if the application destroys the shared resource between driver and application or vice versa.

    --- misbah

    Senior Design Engineer T.E.S Electroni Solutions (Bangalore-India)

    Thursday, April 26, 2012 9:19 AM
  • > You can call this as init (Unix based name)

    Names from other domains than "Windows Embedded Compact Platform Development" might be tending to be confusion here. Therefore I asked for clarification.

    > Which thread are you referring to ?

    Please let me expalin in detail: The client process creates two threads. Although Windows CE does not have the feature of thread names, just designate them with A and B. There might be an additional thread in the driver, but this is not involved here.

    The thread A of the client process calls a driver function, let's say using DeviceIoControl. The thread is owned be the client process. When the thread has migrated to the device driver, it runs in the address space of the  process device.exe. Here are two critical sections (CS1 and CS2). They are used hierarchical, i.e. the thread A enters the first critical section CS1 and while it is in the CS1 it will enter the CS2. Let's assume that the CS2 is locked by third process for a moment, thread A waits at EnterCriticalSection(&CS2);

    The thread B of the client process does not call the driver at all. The most important thing is to fail with an exception, e.g. access violation.

    Now the thread B (that is not in the driver) causes that the process will die. The problem is, that the thread A currently owns the CS1 and probably some further resources.

    1. Does the thread A (locked CS2 and waiting at CS2) terminates immediately?
    2. Does the kernel removes all locks at all critical sections that are locked by the thread A?
    3. What is with heap objects that thread A had allocated/owned/locked for the time it runs in the driver?
    4. Does the kernel somehow indicate that the thread B will not return because the owning process dies?

    I assume that the kernel closes all handles of the dying client process. One of the handles is the driver handle, what causes a call to the XXX_Close function. Is this the only way for the driver to identify that the client has died? How can it repair the state of the critical sections?

    Any pointer to documentation is welcome as I would like to get deeper understanding of how the process is dying. I must also admit that it is strange setup. But as a driver developer I am responsible for a robust driver implementation.


    Thursday, April 26, 2012 11:20 AM
  • If the process dies either because any thread(s). The whole process dies i.e its entry from the process table is removed and all resources will be freed by the OS (process management, memory management etc).

    If the process locks any resource will be freed by the OS, the time is not deterministic in this case.

    The driver or kernel will  never get affected due to this.

    The driver will have problems when it tries to do anything ill legal. And will never become the victim of others  sin.

    Driver should check for inputs passed to it by the user application. (pointer to memory)

    Yes the driver will be closed, as asked by you.

    I am not sure about the wince documention in this regard, but you will find lots of documentation under UNIX/Linux. The concept will remain the same, hence you can refer those also.

    --- Misbah

    Senior Design Engineer T.E.S Electroni Solutions (Bangalore-India)

    • Proposed as answer by Misbah Khan Monday, May 7, 2012 1:09 PM
    • Unproposed as answer by Harper23 Wednesday, May 9, 2012 5:56 AM
    Friday, April 27, 2012 9:52 AM
  • Doing anything illegal should be bad everywhere, not only in a driver, shouldn't it?

    More or less each module should verify inputs passed, additionally the driver needs to setup correct access to the caller process.

    I doubt that the documentation of other operating systems will give information how this specific problem is handledin Windows CE 5.0. Especially the release of resources in the heap should be highly implementation dependend.

    What do you understand by "The driver or kernel will never affected due to this." Does the process termination prevents any memory leak if the thread has allocated a memory block on the heap when the process is dying?

    Or is the driver responsible when the driver handle is closed (by calling th XXX_Close function)?

    Tuesday, May 8, 2012 6:44 AM