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.

I'd like my application to be able to run on .NET 1.1, so I've avoided using all the new niceties of .NET 2.0.

Or so I thought.

First, I experimented with MSBee, which lets you build for the .NET 1.1 environment using the VS 2005 tools. After seeing how many errors my code generated in 1.1, while it compiled cleanly in 2.0, I thought "maybe reimplementing this in VS 2003 might be easier".
And while I've specifically avoided some of the .NET 2.0 things that would have been really handy, like the SecurityIdentifier class, which makes handling SID-account mapping easy, there's things I didn't know would be a problem. You can't set a registry key to be a certain type in 1.1. And you can't use half the features that the designer implements for you automatically. And even if you could, you'd have to hack at it, because they separate code and design with partial classes in 2.0.

So, to summarize, looks like .NET was pretty crap prior to 2005. And that means you need to have XP SP2, because it's not supported on SP1.

(/rant)

Trying to unload a registry hive and finding access is denied?

I was loading in a user hive (NTUSER.DAT in the profile), and then opening the key using RegOpenKey (exposed as Registry.Users.OpenSubKey in .NET) to prove it was successful. However, I'd forgot to close this key, so the handle was staying open and thus you couldn't unload the hive.

Oddly, after some time, the handle would clean itself up, so it seemed more like a time or permissions based issue. Simple fix however.

A working release of ProfileTool isn't far away..