3

I’m working on an application for a motion tracking device and have discovered some odd behavior that got me curious. The device SDK consists of three DLLs, one of them (the main referenced DLL being used in the application) non-native, and the other two native.

The application has three main actors, the Controller (connection between device and application), Listener (receives tracking information) and an endless stream of Frame objects (the data the Listener receives). All these items are disposable, in turn I believe they use unmanaged resources.

If I do not remove the listener from the controller and then dispose of the controller, the application will crash on subsequent startup. This behavior is sporadic, it might happened at the second, third or later startup.

Although I am making sure I am disposing the objects, I’m still very curious what logic or lack of logic can cause this type of behavior. Because I expect all objects to be disposed when an executable stops running.

Could the device drivers hold onto a reference? And what would be the best way to troubleshoot this? So the question is not how to dispose, but what would/could cause this, and why- and how can I Sherlock Holmes this.

More information:

  • No exceptions
  • Attaching a debugger doesn't provide more information
Iris Classon
  • 5,752
  • 3
  • 33
  • 52
  • Do you know what causes the crash on a subsequent startup? What exception you're getting? If you can't find that out, try [attaching a debugger on process start](http://stackoverflow.com/a/12778864/8205) to find out. – Igal Tabachnik Aug 18 '13 at 09:22
  • There are no exceptions- nothing. Attaching a debugger didn't help either. – Iris Classon Aug 18 '13 at 09:24
  • Can you provide some more detail on where/how it crashes on subsequent startup? – Anders Abel Aug 18 '13 at 09:31
  • I guess, the listener registers a callback with the driver, so when the driver has a new frame ready it calls back into the listener. IF this is true, the listener is kept in memory if it's not unregistered from the driver, as the driver is kept alive. If you register it again, when you start the app again, some object is still receiving data from driver, which might crash or the registration again fails and it crashes the listener. – Frans Bouma Aug 18 '13 at 10:04
  • If it "just" crashes, without any managed exception, the crash might be in unmanaged code. You could try launching the process with WinDbg attached, it will surely tell you what crashed. – Igal Tabachnik Aug 18 '13 at 10:50
  • Try to configure VS to debug unmanaged code, http://msdn.microsoft.com/en-us/library/tdw0c6sf(v=vs.90).aspx. – Mikael Sundberg Aug 18 '13 at 11:28
  • Make sure you unregistered the listener before disposal and your problem should disappear :) – Razor Aug 18 '13 at 14:50
  • @VincePanuccio: When the process ends (even if it is an unexpected termination) the driver and any supporting processes/services should automatically release all resources held by the process, so that should not be relevant when the process restarts. – Anders Abel Aug 18 '13 at 17:47
  • Vince: " So the question is NOT how to dispose, but what would/could cause this, and why- and how can I Sherlock Holmes this." The question is not how to make the problem go away. Its about the logic behind the problem. – Iris Classon Aug 18 '13 at 18:55
  • That's the whole point of disposing unmanaged resources. If you forget, all manner of unpredictable things can happen. In your case by not disposing, the unmanaged resource has probably been left in an open/locked state (depending on what that resource is). The next time you run the app it fails because it can't access that resource. – Andrew Stephens Aug 18 '13 at 19:40
  • It's all too easy to forget in our nice managed code world that closing an application will *not* necessarily close/dispose unmanaged resources. – Andrew Stephens Aug 18 '13 at 19:42
  • In the unmanaged world, the operating system/drivers/services should release everything if a process crashes. It's even recommended sometimes to speed up shut down of a process to *not* close files etc. on exit but rather let the OS deal with it. – Anders Abel Aug 19 '13 at 06:36
  • @AndersAbel, The OS will release handles, memory etc in the user process, but a driver will live in Kernel space and won't clean up its resources when a user-mode process exits, they are completely separate. – josh poley Sep 13 '13 at 23:31

0 Answers0