Best practices remote debugging using VS2010 under VS2013

Question

I'm looking for tips for those who to develop for Windows XP embedded in Visual Studio2013, then debug in Visual Studio 2010.

The reasons for this are discussed in this Stack Overflow Link on the topic.

Essentially the remote debug protocol changed after VS2010, and the new msvsmon.exe which uses the new VS2013 protocol doesn't support XP embedded debugging. So we are forced into a TWO IDE solution, one for builds, another for debug. VS2013 is used for builds, and VS2010 is used to launch remote debug sessions.

There is some misinformation about the requirement to purchase both VS2013 and VS2010. It appears from the previously mentioned link, that it's possible to obtain the VS2010 debug environment for free. I was able to verify the free download of the components, but haven't had time to validate that the debug environment works. The environment I use consists of a licensed copy of VS2013 and a licensed copy of VS2010.

Here are two initial problems which I haven't seen doing remote debug in the former VS6 msvsmon.exe environment:

1) With VS2013 build projects, VS2010 does not want to open the *.sln file. If I open the VS6 .dsp/.dsw we ported from VS2010 does a "ONE TIME CONVERSION" which destroys my painstakenly built VS2013 build project. It seems I will have to build TWO different solution spaces, one named SOLUTION_NAME_VS2013 and another SOLUTION_NAME_VS2010. I'm interested to know if there is a more elegant solution to manage 1 set of BUILD files with two different "Highlander" (there can be only one) IDE's.

2) When starting up the project remotely, if it crashes I get one of those annoying "Your program has crashed" dialogs on the Win2012 debug host (running VS2010), which is trapping the crash signal from the debugger. About 30% of the time, it detects the running instance of VS2010, 70% of the time it doesn't.

3) msvmon times out (needs restarting) and requires extra time/mouse clicks to setup over the old vs6 msvcmon.exe

I'm wondering if other Windows Embedded developers have discovered elegant solutions for these issues. I'll post what I find here if I find any more tips moving forward.

---

Answer 1

For Issue #1: Unable to read VS2013 *.sln file in VS2010 .

The problem was that the VERSION of Visual Studio 2010 must be at least SERVICE PACK1. Earlier versions of Visual Studio 2010 cannot read the VS2012/VS2013/VS2015 solution files.

For Issue #2: Your program has crashed dialog preventing signals from reaching debugger .

This Stack Overflow link was helpful. There are multiple ways to suppress the "Your program has crashed" dialog. In my case, users may need to debug new applications on a production system, so changing the setting globally is not ideal.

I choose the solution from this Raymond Chen link it allows me to disable the dialog box on an application by application basis. Since I typically have access to source code I'm debugging this was the best solution for me.

DWORD dwMode = SetErrorMode(SEM_NOGPFAULTERRORBOX);
SetErrorMode(dwMode | SEM_NOGPFAULTERRORBOX);

I still see an issue occasionally with the Windows runtime not seeing the running debugger instance on a crash and wanting to initiate a new one. This seems to happen ~30% of the time. When I figure out what is causing that I will update it here.

Finally, the new remote debug client changed to msvmon.exe which has improved security. To save the extra mouse clicks, the following command is usefull to run on the remote Windows Embedded XP client:

"Path\to\msvsmon.exe" /anyuser /noauth /nosecuritywarn /timeout:2147483646

The /noauth and /anyuser require /nosecuritywarn . /timeout max value keeps the debugger client from terminating after ~ hour of idle time. If your workday is to be spent debugging you don't want it timing out after a coffee/rebuild all break.