It’s a problem we as developers face time and time again, it works on my box but for some reason it doesn’t work on the customer’s machine and it’s not reporting anything useful in the error stream.
Maybe we could install Visual Studio on the customer’s machine and run it in debug? Maybe, probably not. Even if the customer lets you it probably involves punting significant chunks of binary around the place, a lengthy install and although Microsoft probably won’t mind as long as you uninstall it when you’re done it probably does violate your Visual Studio licence.
A much lighter alternative is to use the .NET Command Line Debugger. It’s available as part of the Windows SDK which is significantly less hassle to install than VS and far less likely to get you into trouble with the customer or with Microsoft.
The debugger is
MDBG.exe and is likely to be in
C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin (which you might consider adding to the PATH).
—=== Edit 2013-08-30 ===—
In fact a little research indicates that you can be even more lightweight by installing the relevant parts of the Windows SDK on another box and then just copying
MdbgCore.dll to a temporary directory on the target machine.
—=== End of Edit ===—
—=== Edit 2014-11-21 ===—
In an update that could easily be decorated with the attribute [FFS] it appears that
mdbg.exe is no longer part of the Windows SDK. Instead it can be found as a “sample debug program”—=== End of Edit ===—
You can load the executable you need on the command line, e.g.
C:\Program Files\MyCompany\MyProduct>mdbg MyProduct.exe
Ah, that’ll be it. I’ve made a typo in one of the XML config files. That’ll be a new item for the backlog then, “Make the app write some useful information to the error stream when some numpty screws up the XML“. It’s fine that it terminates, just not that it gives no reason for terminating.
Back on topic, MDBG.exe itself is easy enough to use, it’s even good enough to list its basic usage in response to a ?