RegCreateKeyEx

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

RegCreateKeyEx always fails on Vista 64-bit. The error code is 5. Does
anyone know what is necessary to allow Reg Key creation on Vista 64?
 
Anything under HKLM or KHCR. For example:
lRet = RegCreateKeyEx ( HKEY_CLASSES_ROOT, pszServerName, 0, NULL,
REG_OPTION_NON_VOLATILE, KEY_WRITE, NULL, &hKey, &dwDispos ) ;
 
In Windows Vista, your program runs as a standard ("limited") user, even
when the user is logged in as an administrator.

If your program is compiled to a 64-bit executable and runs on a 64-bit
system, and you try to create/modify a registry key outside of HKCU, you
will get an access denied error.

If your program is compiled to a 32-bit executable, Windows will "redirect"
all of your illegal registry writes to HKCU, most likely causing your
application to misbehave, since it believes it is changing system settings
when it really isn't.

If your application MUST write to these registry keys, for example as an
installer or whatnot, you will need to add a manifest to your application
that instructs Windows to ask the user for permission to run the program
with administrator privileges. This will allow your program to write to
these registry areas, at the price of making the user give permission to
allow your program to run every time. Here's more info on that:

http://msdn.microsoft.com/windowsvi...l=/library/en-us/dnlong/html/AccProtVista.asp
http://www.microsoft.com/whdc/winlogo/LH_logo.mspx

However, if your application does not have a good reason for writing to
these registry areas, it should be modified to write to HKCU instead.
 
Hello Mr. Brush,

In another thread, your recommended that in order to circumvent the vista
permissions dialogs that they build their .net application with a manifest in
a particular way.

I replied to your response but am not sure it was sent out as I cannot find
it now!

So may I ask it here?

How would I do the equivalent from C++?

thanks!


--
Thanks so much,

george

_________________________
George S. Lockwood
Lead Client Developer
peoplePC, an EarthLink company
 
Hi Jimmy,
If your program is compiled to a 32-bit executable, Windows will
"redirect" all of your illegal registry writes to HKCU, most likely
causing your application to misbehave, since it believes it is changing
system settings when it really isn't.
Click to expand...

How can we turn off the 32bit redirect feature, so it just says "Access
Denied"?
 
Hello,

This can be done via group policy.

- Click start
- Type: local security policy
- Expand local policies in the left
- Click security options
- Double-click "User account control: Virtualize file and registry write
failures to per-user locations"
- Click Disabled
- Click OK

This will affect all applications running on that computer.

This will greatly affect application compatability ... There are a lot of
programs that rely on being able to write to off-limits folders and registry
keys :)

However, if all the applications you use do not need this compatability
feature, I do recommend turning it off because of the problems it can cause.
 
Hi Jimmy,
This can be done via group policy.
Click to expand...

- Double-click "User account control: Virtualize file and registry write
failures to per-user locations"
- Click Disabled
Click to expand...
This will affect all applications running on that computer.
Click to expand...

OK, this is cool!
This will greatly affect application compatability ... There are a lot
of programs that rely on being able to write to off-limits folders and
registry keys :)

However, if all the applications you use do not need this compatability
feature, I do recommend turning it off because of the problems it can
cause.
Click to expand...

Well I don't know the answer yet, but surely you are supposed to
_install_ programs with Admin rights (in the middle of the night) and
then the users _run_ them with user rights (during the day). That's how
I've been doing it since year 2000. The way I see it, this registry
re-direction is a WEAKENING of security. If a virus wants to write to
HKLM is should say "Access Denied", not re-direct it!
 
Well I don't know the answer yet, but surely you are supposed to _install_
programs with Admin rights (in the middle of the night) and then the users
_run_ them with user rights (during the day). That's how I've been doing
it since year 2000. The way I see it, this registry re-direction is a
WEAKENING of security. If a virus wants to write to HKLM is should say
"Access Denied", not re-direct it!
Click to expand...

I agree with you. However, thousands of application developers don't seem to
get it :)
 
Hi Jimmy,

I don't like this website, I think it's just PR and propaganda. Do you
have any concrete examples of a known application, and how it worked
under XP, why it "doesn't get it" (your earlier quote) and how the
redirection of registry keys suddenly "fixes" it (if it was indeed
broken in the first place?)
 
Ok, off the top of my head, I will use e-mule as an example.

E-mule creates a folder under program files to store files as they are
downloaded. The permissions on program files allows admins full control, but
standard users read/execute only.

This behavior works fine on XP when running as an admin or power user.

This is incorrect behavior (it "doesn't get it") because programs files is
for storing program files ONLY - the files necessary for the program to
execute. It is not for storing any other data, especially per-user data such
as the users downloads, and the folders/file within program files are
intended to only be modified durring program installation/maintenance.

The design of the program is broken, as it is violating an abstraction that
is enforced by Windows.

So, under Windows Vista, the creation of the downloads folder succeeds when
the installation programs runs, as the installation program is running with
admin permissions; however, when the client attempts to save the files, they
are virtualized. This allows the program to function, where it would have
errored out with "access denied" if this functionality were not in place.

I have said before (and will say again) Virtualization is nowhere near
perfect and can lead to other problems - for example, in the e-mule example,
users will have a difficult time finding their downloads from outside of the
e-mule client.

In fact, you may say that it would have been better for virtualization not
to have interfered, as the behavior of virtualization in this case is no
better than the "access denied" behavior - and in my opinion, that would be
a correct assessment.

However, in cases like these, BOTH ACTIONS lead to bugs - virtualization AND
the original actions of the program.

There are cases where virtualization will allow a program to work correctly
without incurring this price. For example, if a program stores a temporary
file to c:\, which is security-restricted, and dies with some obscure error
if it is unable to correctly save this temporary file, virtualization would
allow this program to work CORRECTLY with no side effects, whereas without
virtualization the program would have failed.

My point here, is that I agree virtualization often doesn't have GREAT
results; but, the cases where it fails are usually cases where the program
would have failed anyway, and virtualization does allow programs to work
just fine where without virtualization they would not have worked at all
(how about popular .exe unzipper programs that default to extracting
setup/temporary files to c:\ or some other security-restricted directory?)

So, without virtualization, many programs will fail. With virtualization,
some programs will still fail, but some will automagically start working.

I can see why MS decided to go ahead and implement it, although I do agree
that in some cases it causes more problems than without :)

I doubt virtualization will be around in the next release of Windows, so
hopefully this will be a moot point soon.
 
Hi Jimmy,

OK, e-mule isn't exactly the kind of thing I'd imagine to see on
thousands of corporate desktops, but it's still an example.

In this case I'd say two things:

1. Write to the e-mule guys if they really are using "Program Files",
this is plain wrong, and they should fix it. It's not Microsoft's job to
worry about this kind of thing because e-mule doesn't comply with
Windows Application Spec.

2. Allow MACHINE\Users modify access to the e-mule sub-folder

But I hardly EVER see this kind of problem, the last program I remember
that did this was DreamWeaver 4, everything else correctly uses the User
profile within the "Documents and Settings" tree.

Changing the whole design of Windows so people can run e-mule seems a
bit extreme!
 
1. Write to the e-mule guys if they really are using "Program Files",
Click to expand...

Doesn't help users using old versions of e-mule.

2. Allow MACHINE\Users modify access to the e-mule sub-folder
Click to expand...

A nasty app compatability hack that could affect system security, since
files stored there could be accessed/modified between user accounts.
But I hardly EVER see this kind of problem, the last program I remember
that did this was DreamWeaver 4, everything else correctly uses the User
profile within the "Documents and Settings" tree.
Click to expand...

I highly doubt this is the only program that does this ;). Personally, I
have answered a few questions from developers on these forums asking why
their program doesn't work when they try to do this, and this isn't even a
dev-related newsgroup.
Changing the whole design of Windows so people can run e-mule seems a bit
extreme!
Click to expand...

That was only one example. There are undoubtedly thousands more, however I
am not going to install and analyze all of them in order to prove a point ;)
 
Back
Top