• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

RegCreateKeyEx

I

Ike Starnes

#1
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?
 

My Computer

I

Ike Starnes

#3
Anything under HKLM or KHCR. For example:
lRet = RegCreateKeyEx ( HKEY_CLASSES_ROOT, pszServerName, 0, NULL,
REG_OPTION_NON_VOLATILE, KEY_WRITE, NULL, &hKey, &dwDispos ) ;


"Jimmy Brush" wrote:

> What registry key are you trying to create?
>
>
> --
> - JB
>
> Windows Vista Support Faq
> http://www.jimmah.com/vista/
 

My Computer

J

Jimmy Brush

#4
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.


--
- JB

Windows Vista Support Faq
http://www.jimmah.com/vista/
 

My Computer

G

GSLockwood (IUnknown)

#5
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



"Jimmy Brush" wrote:

> What registry key are you trying to create?
>
>
> --
> - JB
>
> Windows Vista Support Faq
> http://www.jimmah.com/vista/
 

My Computer

G

Gerry Hickman

#6
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.


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

--
Gerry Hickman (London UK)
 

My Computer

J

Jimmy Brush

#7
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.

--
- JB

Windows Vista Support Faq
http://www.jimmah.com/vista/
 

My Computer

G

Gerry Hickman

#8
Hi Jimmy,

> This can be done via group policy.


<snip>

> - Double-click "User account control: Virtualize file and registry write
> failures to per-user locations"
> - Click Disabled


> This will affect all applications running on that computer.


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.


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!

--
Gerry Hickman (London UK)
 

My Computer

J

Jimmy Brush

#9
> 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!


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


--
- JB

Windows Vista Support Faq
http://www.jimmah.com/vista/
 

My Computer

G

Gerry Hickman

#10
Hi Jimmy,

>> 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!

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


Can you name any well-known applications that "don't get it"?

--
Gerry Hickman (London UK)
 

My Computer

G

Gerry Hickman

#12
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?)

> Not specifically, I am basing my information off of this webcast:
>
> http://channel9.msdn.com/Showpost.aspx?postid=255622
>
> Where they say that after virtualization and other such shims were put
> in place, app compat jumped from around 50 to 90 percent.


--
Gerry Hickman (London UK)
 

My Computer

J

Jimmy Brush

#13
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.

--
- JB

Windows Vista Support Faq
http://www.jimmah.com/vista/
 

My Computer

G

Gerry Hickman

#14
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!

Jimmy Brush wrote:
> 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.
>



--
Gerry Hickman (London UK)
 

My Computer

J

Jimmy Brush

#15
<snip>
> 1. Write to the e-mule guys if they really are using "Program Files",


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

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


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.


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!


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 ;)


--
- JB

Windows Vista Support Faq
http://www.jimmah.com/vista/
 

My Computer

Users Who Are Viewing This Thread (Users: 1, Guests: 0)