Question

In Visual Studio’s Attach to Process dialog, one of the columns in the Available Processes list is “Title”, which lists the title of the topmost window owned by each process.

We spawn multiple instances of several server processes in order to compartmentalize the work. For these console processes, the Title field is blank, so currently we have to look up the process id in our management tool in order to find the correct process.

In order to streamline the debugging process, I would love to be able to use the Title field to directly determine which process I want.

SetConsoleTitle does not do the trick, nor SetWindowText with a NULL hWnd. To the best of my knowledge, a console application does not intrinsically own any window handles that we could pass to SetWindowText. We don’t want to create any visible windows for these server processes.

Any suggestions for a reasonable way to trick Visual Studio into displaying some useful information here?

Answer 1

I think you might be out of luck. The console window does not belong to the console process, but instead belongs to a system process (conhost.exe on win7 and maybe vista, csrss.exe before that) so if Visual Studio is just looking for a processes top level windows it won’t find the console window. Probing consoles out of proc is not supported as far as I know, so there is probably no sensible way for visual studio to see the title of the console windows you have.

One possible solution might be to create a top level window in your console process as a debugging aid. You might want to conditionally compile it, so it is only available when you’re debugging though. Just create an additional thread which pumps messages, and create a top level window. If you set the right styles the window will be invisible. You might not want to ship with the window in the code because in long running server code, windows always increase your attack surface, even if only a little bit.

This is probably not very helpful, but it is worth mentioning that on windows the preferred way of portioning up work would be to use threads rather than multiple processes. A process is an expensive object, and threads are much cheaper in terms of system resources as well as being easier to debug.