Off the record - Craig Box

ProfileTool doesn't work on half the machines I try it on. I get an error like:

Profiletool.exe Common Language Runtime Debugging Services
Application has generated an exception that could not be handled.
Process ID=0x14 (1300), Thread Id=0xe8(232)

Click OK to terminate the application.
Click CANCEL to debug the application.

There's no point searching Google for the process ID and thread number; they're unique to your instance.

What can you do here? You get an error suggesting that 'debugging failed' if you hit Cancel - this is correct, because you don't have a debugger installed!

First step, if you're running your .NET application off the network, stop, move it to your local disk, and try again. The default security policy doesn't let you do this - you can edit it in the Administrative Tools if you need to.

Now, if you still get the error, drop to a command line, and run the following:

ProfileTool 2>error.log

This redirects the standard error output to error.log, which you can then read. Linux/UNIX outputs this to the terminal by default; Windows hides it.

Thanks to Frank Racis, by way of Mohamed Yehia.

The actual error, in this case, was "No mapping between user accounts and security IDs was done", which really means "don't catch System.SystemException when you are throwing System.Exception". And when you're testing new builds, don't sit behind an ISA server which aggressively caches the old build.

Tags: dotnet, programming, windows

This entry was posted on Friday, May 11th, 2007 at 6:43 pm and is filed under Technical, Work. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.