I’ve been fiddling with COM components lately, trying to set up a simple server application that allows late binding so that I can call the API from languages other than C/C++, but I soon ran into an interesting permissions problem when trying to register the object for the second time (don’t ask): RegCreateKeyEx in my DllRegisterServer() function was returning ERROR_ACCESS_DENIED (5) even though I was running an account with administrative rights. I found this rather puzzling, and the worst part was that regsvr32.exe returned with a misleading success message.

After some Googling, I ran across an article which suggested that I change the permissions of the HKCR and HKCR\CLSID registry keys. I eventually did this, explicitly enabling full control to both them and their sub-keys for all users,  but with no success. The solution, I eventually found, was to launch Visual Studio itself in administrative mode, which did the trick (maybe this should have been my first step, but hey, my account is an admin account!).

After all this, it seems to me that registering a COM component shouldn’t require administrative access; at the very least, it would be nice if I just had to confirm the registry change — which I would like to think User Account Control would be capable of discerning. Also, because I didn’t have any sort of problem registering the component for the first time (I was running Vista at the time), I kind of wonder if this is a Windows 7 RC fluke or just an intentional permissions lock-down on the new-and-improved version of UAC.

Update: Disabling UAC completely also allowed the component to register.

A quick tip on the side (not my own): Note that I have VS set up to use regsvr32.exe to “run” the debug profile so that the code can be debugged within the IDE. To do this, open the properties page for your COM server project, click on the debugging section, enter “regsvr32.exe” into the Command box, and “”$(TargetPath)”" into  Command Arguments (you need one pair of quotes for the latter).

I’ve been eagerly awaiting the 2.0 release of MonoDevelop, which happened a bit ago but it took a while to hit the Ubuntu 9.04 Beta repositories. I’d forgotten about it until today, when I was trying to use the alpha 1 release to do some work on GCast; however, it’s been so long since I attacked the code base that for the life of me I could not track down a bug that had recently reared its ugly head. I’d made too many changes since the last SVN commit, so diff’ing a bunch of files was like looking for a needle in a haystack.

Thank goodness, after installing MonoDevelop 2.0 with its integrated debugger, it took all of a few minutes to find the problem. I don’t know how I’ve survived this far on this particular project without a debugger — I’ve had to resort to GDB and MDB at the command line a few times, but only reluctantly — wish I could reclaim the lost time. Kudos to the MonoDevelop developers for making a great product even easier to use!

Get MonoDevelop 2.0 at: http://monodevelop.com/

Today I’m happy to announce that the first beta of APID, the Win32 API Debugger, is available:

APID is a small personal project that I’ve worked on intermittently for about a year and a half or so, mostly because I thought it would be a fun app to create. One of its technical features is that it avoids the Import Address Table (IAT), which simply makes it harder (I hope) for applications to avoid APID by using a packer/obfuscator on their application.

Try it out and let me know what you think in the comments area.

Link to download page (Beta 0.1)