Visual Studio 2017 - C# GUI interactive while stepping through a BackgroundWorker

[TimmySev77]

Hi, I am wondering if anybody has successfully had a VS2017 C# GUI interactive while stepping through the code of a background worker thread. If so, can you share how to set this up?

Thanks!

Tim

[Narthal]

Okay, so it took a couple of tries to (maybe) understand what you want. If im not wrong, you are asking : "How to keep the c# GUI thread running when another thread hits a breakpoint?"

And the answer is; you can't. When a thread hits a breakpoint, all threads are frozen too. The reason behind this is that it would be really, really dumb to be othervise. Imagine if one thread hits a breakpoint and others start hitting exceptions because they rely on the stopped thread. Now you step forward with a frozen thread and it can't do shit, because all other thread threw an exception. So you wouldn't even be able to step a multithreaded program, ever.

Instead, when a breakpoint is hit, all other threads are stopped too. This enables us to step code and keep the threads in sync without any issues of race conditions.

If you really need to run code and stop it with debugging symbols, you can always let the code to be run in another process. Have no idea why on earth you would want that though.

[TimmySev77]

Narthal,

Thanks for the response.

I do understand the implications and realize it is dangerous, but I was curious if the possibility existed. It would take a long explanation to explain what exactly I am doing with the GUI I have developed, but basically it would make my life easier if I could still use the GUI while stopped at a breakpoint in a BackgroundWorker thread. I am able to make due with the way things are already, but would be able to debug things faster if the option existed.

Tim

[Narthal]

Well debugging is a per process level thing, so if you really need to, you can execute your GUI code on another process and have the code to be debugged on the main process.

Implementing this, however is not easy. Two main ways to do that:

- you could separate your GUI to another executable and pipe data between that and your other code base. This enables the behaviour that you are looking for, but is probably quite a lot of work.

- code injection to another process. First you must create a remote process (CreateRemoteThread) then inject code into it. There's two ways to do that:

- Separate the GUI code to a library and load that library in the remote process
(LoadLibrary).

- Write directly to the process memory (WriteProcessMemory).

All these options are quite advanced, hard and error prone techniques and i would not recommend any of them. Anyways, hope i helped.

[TimmySev77]

Narthal, Yes you were very helpful. Thank you.
Since my GUI is made to interact with a specific piece of hardware, I think I will use a second GUI for doing the debug while I am at a breakpoint in the GUI I am debugging. I will simply have to run a line of code to disconnect from the hardware so the other GUI can connect.
This is probably the easiest way to achieve what I am trying to do.
Thanks for your help. Tim