RegistryKey.OpenSubKey fails with SecurityException

[=?Utf-8?B?RGF2aWQgSw==?=]

I have some C# code I am using to delete a subkey and its tree from the
registry however I am running into some issues.

At first, I was using the Registry.LocalMachine.DeleteSubKeyTree method and
passing it a string like this:

SubKeyBase = @"SYSTEM\CurrentControlSet\Enum\";
Registry.LocalMachine.DeleteSubKeyTree(SubKeyBase + InstanceID);

The variable InstanceID had something like this in it:

USB\VID_xxxx&PID_xxxx\xxxxxxxxxxxxx

This is the instance ID of a USB device and it correlates exactly to the
information stored about the device in the registry. By appending these two,
I came up with the path to the registry key/tree that I wanted to delete:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\U SB\VID_xxxx&PID_xxxx\xxxxxxxxxxxxx

Using this approach, I was getting an ArgumentException saying that the key
does not exist, however I could open up regedit and the key was there and I
could delete it manually if I wanted without a problem. So since I couldn't
figure out what was going on, I decided to use OpenSubKey to open the path
defined by SubKeyBase (ie. "SYSTEM\CurrentControlSet\Enum") and then use that
RegistryKey object to delete the key/tree I needed and see if I got any
different result.

RegistryKey rk = Registry.LocalMachine.OpenSubKey(SubKeyBase, true);

(The 2nd argument with a value of true is to indicate I need write access)

Well, this statement is throwing a SecurityException even though I can
manually open up regedit and delete the key. I am a fairly new to the .NET
framework so I am not sure what I need to give my application the security
clearance to perform these operations. I was under the impression that it
automatically inherited the security profile of the user running the
application but it seems this is not the case.

Any help is greatly appreciated!

Regards,

David K

[Family Tree Mike]

By chance, are you using a 64 bit OS? Something similar drove me crazy
until I read about registry virtualization under such OSs.

"David K" <Da****@discussions.microsoft.comwrote in message
news:B5**********************************@microsof t.com...

>I have some C# code I am using to delete a subkey and its tree from the
registry however I am running into some issues.

At first, I was using the Registry.LocalMachine.DeleteSubKeyTree method
and
passing it a string like this:

SubKeyBase = @"SYSTEM\CurrentControlSet\Enum\";
Registry.LocalMachine.DeleteSubKeyTree(SubKeyBase + InstanceID);

The variable InstanceID had something like this in it:

USB\VID_xxxx&PID_xxxx\xxxxxxxxxxxxx

This is the instance ID of a USB device and it correlates exactly to the
information stored about the device in the registry. By appending these
two,
I came up with the path to the registry key/tree that I wanted to delete:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\U SB\VID_xxxx&PID_xxxx\xxxxxxxxxxxxx

Using this approach, I was getting an ArgumentException saying that the
key
does not exist, however I could open up regedit and the key was there and
I
could delete it manually if I wanted without a problem. So since I
couldn't
figure out what was going on, I decided to use OpenSubKey to open the path
defined by SubKeyBase (ie. "SYSTEM\CurrentControlSet\Enum") and then use
that
RegistryKey object to delete the key/tree I needed and see if I got any
different result.

RegistryKey rk = Registry.LocalMachine.OpenSubKey(SubKeyBase, true);

(The 2nd argument with a value of true is to indicate I need write access)

Well, this statement is throwing a SecurityException even though I can
manually open up regedit and delete the key. I am a fairly new to the
.NET
framework so I am not sure what I need to give my application the security
clearance to perform these operations. I was under the impression that it
automatically inherited the security profile of the user running the
application but it seems this is not the case.

Any help is greatly appreciated!

Regards,

David K

[=?Utf-8?B?RGF2aWQgSw==?=]

Sorry, I entirely forgot to mention the OS it's on. This is under Windows XP
Pro, so not a 64-bit OS. Any other ideas?

"Family Tree Mike" wrote:

By chance, are you using a 64 bit OS? Something similar drove me crazy
until I read about registry virtualization under such OSs.

"David K" <Da****@discussions.microsoft.comwrote in message
news:B5**********************************@microsof t.com...

I have some C# code I am using to delete a subkey and its tree from the
registry however I am running into some issues.

At first, I was using the Registry.LocalMachine.DeleteSubKeyTree method
and
passing it a string like this:

SubKeyBase = @"SYSTEM\CurrentControlSet\Enum\";
Registry.LocalMachine.DeleteSubKeyTree(SubKeyBase + InstanceID);

The variable InstanceID had something like this in it:

USB\VID_xxxx&PID_xxxx\xxxxxxxxxxxxx

This is the instance ID of a USB device and it correlates exactly to the
information stored about the device in the registry. By appending these
two,
I came up with the path to the registry key/tree that I wanted to delete:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\U SB\VID_xxxx&PID_xxxx\xxxxxxxxxxxxx

Using this approach, I was getting an ArgumentException saying that the
key
does not exist, however I could open up regedit and the key was there and
I
could delete it manually if I wanted without a problem. So since I
couldn't
figure out what was going on, I decided to use OpenSubKey to open the path
defined by SubKeyBase (ie. "SYSTEM\CurrentControlSet\Enum") and then use
that
RegistryKey object to delete the key/tree I needed and see if I got any
different result.

RegistryKey rk = Registry.LocalMachine.OpenSubKey(SubKeyBase, true);

(The 2nd argument with a value of true is to indicate I need write access)

Well, this statement is throwing a SecurityException even though I can
manually open up regedit and delete the key. I am a fairly new to the
.NET
framework so I am not sure what I need to give my application the security
clearance to perform these operations. I was under the impression that it
automatically inherited the security profile of the user running the
application but it seems this is not the case.

Any help is greatly appreciated!

Regards,

David K