Results 1 to 2 of 2

Thread: TaskCreate excess [CREATE] and [CLOSE] events

  1. #1
    Join Date
    Oct 2016

    Default TaskCreate excess [CREATE] and [CLOSE] events

    I've got a problem that is popping up semi-randomly with some (fairly old) girder installations (Girder 5.0.14 build 551)

    Let me preface by saying that I'm new to both Girder and this project in general. The system includes a proprietary application, as well as Girder (with HTTP control) and several other third-party apps that it controls, as well as a TV. It's running on Windows Embedded Standard SP1 (Looks like Windows 7)

    Anyways, I've spent the last few days trying to debug the errant behavior, though several other parts of the system, and I *think* I've tracked the problem down to Girder responding to events that aren't actually happening...

    Our app runs as a Service...when a playlist is activated, it opens a web page using an embedded instance of Internet Explorer, which displays a series of videos and documents which may in turn open other helper apps to view certain document types. Girder is configured with handlers for TaskCreate [CREATE] and [CLOSE] events on the app, which trigger various startup and cleanup macros. As far as I know, it's been working fine until recent updates to the web content, which is puzzling. Specifically, while the web page remains open, Girder is sometimes triggering extraneous [CREATE] and [CLOSE] events (maybe?)

    The extra [CREATE] events are manageable (and testing on older system builds shows that these have been happening in the past), but the [CLOSE] events are new...and showstoppers...literally. It can turn the TV off in the middle of a playlist...

    The user manual is unhelpful about what exact conditions generate the events...the documentation says: "Generates events when applications start and stop."
    The executable in question is always running on the I wondered if it is tied to creation and destruction of threads and/or windows belonging to the specified executable...

    I've watched the app with Process Monitor and Winspector, watching thread and window lifespans, but there appear to be *many* more threads and windows created and destroyed than [CREATE] and [CLOSE] events generated. I can't see anything happening that directly corresponds to the events.

    Oh yeah...the event handlers have a Window Exists? conditional attached, checking the window name and executable... this explains why the [CREATE] sequence is running more than the the [CLOSE] sequence...the window exists!

    However, I am seeing the occasional [CLOSE] sequence triggering while the window is still appears that sometimes Girder is determining that the window doesn't exist when it does.

    I had the idea that it might be happening at certain times when the app is too busy to respond to some WM_message or another...
    It sort of makes sense, given that this is happening along with the updated web seems the new javascript is increasing the system load a bit (around 65% CPU usage) and, in fact, animations on the page are pretty janky, despite being supposedly offloaded to the GPU, suggesting that CSS animations in IE are running in the same thread as the it possible that the main Windows message loop is also being blocked by the javascript? And would that even matter? Is Girder querying the app directly and timing out?

    I decided to test it by adding a button to the web page that runs a tight loop in javascript for 5 seconds. It blocks all animation on the page, and the first few times I tried it, I immediately saw the [CLOSE] sequence trigger in girder...Eureka!, I thought...

    Unfortunately...I have since been unable to reproduce the behavior using the busy button. Was it a coincidence? I am still seeing the occasional [CLOSE] sequence triggered in the middle of a playlist, but I now have no ideas left as to what is causing it.

    I'd appreciate any insight into what could be happening. Please let me know if there is any more information I can provide that might help... I doubt my employer would appreciate me posting the entire GML file here, but I might be able to post excerpts of the relevant sections (no idea how to do that at the moment, tho)

    -Partap Davis

  2. #2
    Join Date
    Jan 1998
    Jupiter, FL


    [CREATE] and [CLOSE] are fired as a result of HSHELL_WINDOWCREATED and HSHELL_WINDOWDESTROYED via SetWindowsHookEx, so if they are firing incorrectly whereas they used to fire correctly something else is messing with you.

    The Window Exists conditional could potentially return false for a hung window if windows no longer lists it in the EnumProcesses function. In short I'm not entirely sure what is causing your issues.
    No support through PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts