UIThreadProc in notify.dll exits when terminating an application RRS feed

  • Question

  • Our system is a Samsung S3C2410 running Windows CE 5. When starting our main application we first start a startup.exe, which in turn starts the main app.

    We noticed that sometimes the time service didn't work correctly, we didn't get any DST time change events when we were supposed to shift between DST and STD; time and TZ change events didn't work either. The problem occured when we forcibly closed both the main app exe and the startup exe using the remote process viewer and left the platform powered and the OS running.

    After some investigation it turned out that the error was related to notify.dll. When running a debug version of notify.dll we saw the following debug output:

    [NOTIFY] NFY_IOControl 0x010303ff     -> this came when closing the main app
    [NOTIFY] UIThreadProc::Finished.     -> this came when closing the startup exe

    0x010303ff is IOCTL_PSL_NOTIFY, which is sent by the OS when an applications main thread exits, with other threads still running, and with a handle open to the device (NFY in this case).

    When using the remote spy we saw that notify.dll has a status window called WinCENotify. This window receives (WM_USER+3) when an event is triggered by notify.dll, for example time change event that the time service is waiting for. The funny thing was that when terminating the startup.exe the WinCENotify window received W_CLOSE and WM_DESTROY and at the same time we saw the "UIThreadProc::Finished" log message. After this no function related to notifications worked, like CeRunAppAtTime.

    Used the Kernel Tracker we identified threads in services.exe that was doing the work when using notifcation API functions. One of these threads (most likely the UIThreadProc) got a Thread Suspend Event when closing the main app and startup.exe.

    The question is why the WinCENotify window receives WM_CLOSE/DESTROY when we close our main app and startup.exe and thereby causing the notify.dll to break. The remote process viewer must be using TerminateProcess when killing applications (right?) and TerminateProcess is not recommended to use if it can be avoided. So just by using TerminateProcess we could get some unexpected behaviour?

    We are worried that the problem could be related to thread migration and somehow an application thread migrates into notify.dll and gets connected to the WinCENotify window. When we kill our process the WinCENotify window receives a WM_CLOSE. This seems crazy, but I feel that thread migration is a bit crazy. ;-)

    The good thing is that the scenario where we close both the main app and the startup.exe forcibly with TerminateProcess is not present normally (except during code development/testing). The bad thing is that we have some cases when we are forced to use CreateProcess and then TerminateProcess to start and stop some processes from our main app and we are afraid that the problem can occur beacuse of that. Also, the last shift between summer and winter time we had a number of terminals that didn't shift and the fear is that it was related to the notify.dll breaking.

    Any comments are welcome.


    Friday, August 27, 2010 8:05 AM

All replies

  • I doubt this is related to thread migration; it sounds like the notify dll itself must be getting a close message that is causing the notification service to be stopped.  Does this occur when you forcibly terminate a simple "Hello World" application?

    Dean Ramsier eMVP BSQUARE Corporation
    Thursday, September 2, 2010 2:47 PM
  • No, it does not seem to happen when just terminating a simple app. And, no, thread migration is probably not the reason, but since we had a strange bug some time ago related to thread migration we always suspect thread migration.

    As you say, it looks is that the window in the notify dll gets the WM_CLOSE/DESTROY message. But WHY? ;-)



    Monday, September 6, 2010 11:37 AM
  • And why on your application and not on some other unrelated application.  The notification subsystem is global to the platform, not tied to particular applications.  Is there anything unique about your application?  Does notify.dll load in your process space for some reason?
    Dean Ramsier eMVP BSQUARE Corporation
    Tuesday, September 7, 2010 12:44 PM
  • No, the notify dll doesn't load in to our process space, at least not according to the process viewer. Our app uses notification routines of course, like CeSetUserNotificationEx, and waits for events with WaitForSingleObjects, events that are handled by the notify event database (?). But as you say the notify dll is global in the OS. When starting the OS it is loaded in the services.exe process space; I've verified this in the process viewer. I've also let device.exe load the notify dll. Still we get the same error with the notify UIThread closing because the notify WinCENotify window receives WM_CLOSE/DESTROY. Or is it the other way around: the UIThread is terminating for some reason and then the WinCENotify window gets the WM_CLOSE/DESTROY because of it.

    The reason we suspect thread migration (apart from the fact that we had a previous bug because of this) is that thread migration is involved when using the notify subsystem. When calling functions like CeSetUserNotificationEx, WaitForSingleObject somehow we must be migrated into the notify routines via coredll.dll. Is this a correct assumption?

    We are pretty sure that error will not happen in our product when it is used in the field. However it is a strange and pretty serious bug if it happens. So I'm still very interested in finding the reason for it, partly because I would like to know more about how the OS works "under the hood". How can the notify dll break just because I terminate two applications?! Whatever strange things the apps do this should not happen, a pretty obvious statement. ;-)


    Wednesday, September 8, 2010 8:29 AM
  • Thread migration does occur in all these cases, but that's how all OS activity works.  Things happen on the calling thread, and the thread migrates to whatever PSL implements the call. 

    Based on the notify.dll source code (available as part of the premium source code package) the UIThreadProc will exit when the WinCENotify window gets the WM_CLOSE (UIThreadProc contains the message loop for WinCENotify window).   It appears that will occur when the Notification service gets a STOP command, or a REFRESH command.  The REFRESH command should do stop the service then restart it.  I think that forcibly shutting down your app is triggering something that causes the notification service to stop, but don't know why.

    The notify code is available as part of the premium source code package, you might consider signing up for it.  It makes debugging issues like this a lot easier!

    Dean Ramsier eMVP BSQUARE Corporation
    Wednesday, September 8, 2010 2:06 PM
  • Thanks Dean,

    Yes, we'll definitely consider getting the premium source code package (is this available for CE 5?). Previously we've had a number of bugs where lack of source code made debugging really tricky.

    (One final note about thread migration and the reason why we are suspicious about it. The bug we had some time ago was caused by a status monitor window in AutoDial. One of our application threads was migrated into AutoDial through an IOCTL and the AutoDial window's message loop read our internal application messages. When returning from the IOCTL the application thread message queue was empty. In this case our design was flawed since the application thread was doing "too much", not only handling messages. The reason for AutoDial to kick in was that we called getaddrinfo when we didn't have network access causing AutoDial to be triggered.)


    Thursday, September 9, 2010 1:29 PM
  • Here's the link to get you started; it is available for CE5.


    Dean Ramsier eMVP BSQUARE Corporation
    Thursday, September 9, 2010 1:45 PM
  • Thanks Dean,

    Unfortunately it seems our company doesn't meet the criteria to access the source code. Which is a real downer. I really don't understand why MS believe they need to restrict this. Oh well.

    I'll post here if we ever figure out what's causing the strange behaviour. Probably this should have been a discussion thread, not a question.


    Friday, September 10, 2010 12:24 PM
  • If you can narrow down the repro steps you might consider submitting this as a support incident.  You get two free support incidents with Platform Builder, and if it turns out to be a bug in Microsoft code the submission doesn't count against you.

    Depending on the outcome you could push for a QFE although that requires business justification.  Either way, you would know how it might affect devices in the field.

    Dean Ramsier eMVP BSQUARE Corporation
    Monday, September 13, 2010 1:51 PM