0

I have an issue with one of my C# project where the main process will sometimes not exit.

It's an Avalonia 11 project that uses LibUsbDotNet to communicate with a vendor USB peripheral.

Sometimes (~10%), upon closing the main window, the 'console' window will stay there, frozen forever. When trying to break in Visual Studio, the break button gets greyed after being clicked on (as shown in the picture below).

Break button is greyed

When trying to attach a debugger to the process using Windbg, I get the following:

An attempt was made to access an exiting process

So, clearly the process is "exiting". But it never does and I eventually get a debugger timeout.

The error is related to USB communications, most likely within LibUsbDotNet as the process exits as soon as I unplug the device the application interacts with. And so long as the process runs, the handle on that device is not released.

Only one thread possesses the UsbContext, which is a IDisposable, whose Dispose is called in the finalizer of a component instanciated by Autofac in Main.

That's very specific information though, and I'm as interested in the general answer as in solving this particular problem - how can I go about tracking the source down in such a situation where I can't even attach a debugger during process termination to try to figure out what awaits what ?

Julien BERNARD
  • 653
  • 6
  • 17
  • Have you tried attaching the debugger to the process earlier, before you attempt to exit? – John Wu Jun 30 '23 at 22:04
  • In the case of Visual Studio the debugger is attached from the start – Julien BERNARD Jun 30 '23 at 22:36
  • Well, if you are literally unable to use any debugging tool, you can always do it the old-fashioned way, by modifying the code to log its own progress, e.g. `log.Debug` or `Console.WriteLine` even. – John Wu Jun 30 '23 at 22:56
  • That's another thing... I added `System.Console.WriteLine`s followed by `Syustem.Console.Out.Flush`es in the destructor of the object managing all USB things in my application (i.e the likely source of the issue) and they're never called, even when the application completes. – Julien BERNARD Jun 30 '23 at 23:12
  • That's another thing... I suggest moving the Dispose call out of the Finalizer, that isn't a great place for it because you can't be sure which other objects haven't been finalized yet (e.g. console may already have been shut down). Dispose is really meant to be called explicitly as soon as possible in your main code. – John Wu Jul 01 '23 at 01:05
  • If you are writing finalizers (aka destructors), you _really_ need to know the rules and understand wht the rules are there. Bad fnalizers can add very bad behavior to an app. The only things that should be in a finalizers are calls to release unmanaged resources. Also look up the _Dispose Pattern_ in the Microsoft docs – Flydog57 Jul 01 '23 at 16:39

0 Answers0