2

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. CrashDialog

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.

Community
  • 1
  • 1
Ross Youngblood
  • 502
  • 1
  • 3
  • 16
  • Change the ToolsVersion in the .vxproj xml so that a project created in VS2013 can be read and executed in VS2010. Look for: Change to: – Ross Youngblood May 23 '16 at 17:44
  • Suggestion: If the second part of your question is actually a duplicate of http://stackoverflow.com/questions/396369/how-do-i-disable-the-debug-close-application-dialog-on-windows-vista, why not remove that part entirely? Then the question can focus on the first part, "How to debug in both VS2013 & VS2010 with one solution?". Then someone can create a community wiki answer to get the solution out of your question. This would clean up your post a great deal. – BSMP May 26 '16 at 16:32
  • It's not ideal to leave a post like this, so I'll upvote it in the hope that permits you to create an answer. (I don't have sufficient knowledge to know whether the two questions you've asked a so strongly related they must go in the same question, but in general it is a good idea to ask multiple questions in multiple posts, to avoid it being closed as too localised/broad). – halfer May 26 '16 at 16:59
  • Also, whilst I appreciate this is a special case, we generally discourage posters from asking for upvotes here `:-)`. – halfer May 26 '16 at 17:02
  • Thanks for the feedback! @BSMP I'm considering this. I think keeping these two issues together is important for users migrating from Win Server 2003 to WinServer 2012 as this component forces the VS6->VS2013 migration and that forces the addition of VS2010 for debugging. The nderlying embedded debug environment element WindowsXP has not changed. And yet the remote debug environment encounters multiple issues as a result. – Ross Youngblood May 27 '16 at 11:31
  • Great work, thanks for maintaining your questions! No rush. – halfer May 27 '16 at 12:47

1 Answers1

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.

Screenshot of Working vs non Working VS2010

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.

Community
  • 1
  • 1
Ross Youngblood
  • 502
  • 1
  • 3
  • 16