This is a follow-on from:
Debugging a Multithreaded C# – C++/CLI – C++ Solution in Visual Studio 2008: What are these threads?
Please excuse the format, I’ve just repeated some of the description of the application here:
I’ve inherited a project consisting of three levels of code. The lowest layer is native C++ that interacts with hardware. This is mature, stable and well-tested. The intermediate level code is C++/CLI, which interacts with top-level C# code that contains the UI elements and some additional functionality. This C# code is incomplete and was rushed in development: it crashes frequently and is not fit for purpose. My task is debug it and complete it.
I received some very helpful info from the last question I asked – but now there’s more issues! My problem at the moment is that when I invoke Application.Exit() to shut down the UI and quit the application, an exception is thrown:
System.InvalidOperationException: Collection was modified; enumeration operation may not execute
I understand that this is because I need to ensure that all of my threads are ended before I call Application.Exit() (or Application.ExitThread()). I’ve tried using MainForm.Close() as quick fix while I investigate further but it doesn’t alleviate the problem.
I don’t want to just called Thread.CurrentThread.Abort(), mainly because some of the threads originate in the C++ section of the code, via Boost::Thread, and I’m unsure exactly what resources I may leave in an undesirable state (a lot of the code consists of objects for interaction with hardware, such as a serial port – it’s not been implemented via RAII so I’m rather cautious of brute forcing things).
What I’d like to be able to do is identify what threads are doing what, and gracefully end them prior to exiting the application. However, in VS 2008, the stack trace – with ‘Show External Code’ activated – only reveals
[Native to managed transition]
[Managed to native transition]
so I’m still having difficulty tracing the individual native threads and thus working out the best way to end them.
I tried using Allinea DDTLite, which seemed excellent – but I’ve had some issues with my VS installation and I had to disable the plug-ins, so it wasn’t a solution.
To summarise: what is the most effective way to ensure that all threads – both managed and native – are correctly finished so that the UI and then the
the entire application can exit cleanly?
You cannot make this work. There are ways to enumerate the threads in a process, like the managed Process.Threads property or the native Thread32First/Next but you don’t get nearly enough info about the threads to know what they do. And most certainly not to shut them down cleanly. Further complicated by the .NET framework using threads for its own purposes, like the debugger thread and the finalizer thread and a smattering of threadpool threads.
You can kill these threads rudely with TerminateThread, albeit that killing the finalizer thread will crash the program immediately, but that’s no different from rudely terminating the process with Environment.Exit(). With the caveat that nothing is cleaned-up nicely. Windows will clean up most of the shrapnel though.
This should not normally be a problem. You know what threads you started, there should also be a mechanism to ask them to shut down. That’s normally done by signaling an event, something that’s tested in thread’s main loop. Waiting on the thread handle confirms that the thread indeed exited. After which you can close the windows.
But that’s probably plumbing that’s missing, you’ll have to add it. If the current native C++ code has no mechanism to take care of thread shutdown then you’ve got a fairly big problem. I’ll guess that maintaining this native C++ code is the real problem. You may have to hire a gun to get this done.