JEDI Windows API » Registry

TRegistry.DeleteKey and 64bit

Christian Wimmer — Tue, 17 Aug 2010 12:51:19 +0000

I got a bug from someone who told me that he had problems with the TRegistry method DeleteKey on his 64bit Windows. It just didn’t delete a 64bit key* from the registry although he used the KEY_WOW64_64KEY flag in desired access parameter of TRegistry.Create.

At first I thought that it was a problem with the OpenKey function of TRegistry. However, this was already confirmed and fixed as a bug in QC# 23429.

Then I wanted to check the real error value of DeleteKey. Of course, it just returns true or false, so I added a call to GetLastError. And it returned 87 (Invalid Parameter). It must be said that using GetLastError in a framework like VCL is always a problem because you don’t really know how many winapi functions are called subsequent to the actual winapi function. So you may get an error value from another random function. This is one reason I’m using exceptions in JWSCL, btw.
A quick step through debugging session (you have to enable debug dcu in project options and rebuild the project) confirmed that the invalid parameter error (87) came from RegDeleteKey. But why 87? The next step was obvious because I had a windows function and thus I would have to read its MSDN documentation.

It reads:

RegDeleteKey Function
Deletes a subkey and its values. Note that key names are not case sensitive.

64-bit Windows: On WOW64, 32-bit applications view a registry tree that is separate from the registry tree that 64-bit applications view. To enable an application to delete an entry in the alternate registry view, use the RegDeleteKeyEx function.

So the RegDeleteKeyEx function must be used. But don’t stop reading here and implement it. We can’t just use this function because MSDN states that this function is only available in XP 64bit or Vista (32 and 64bit). So this gets more complicated and I suggest this way :

	XP 32bit	XP 64bit	Vista and newer (32+64)
RegDeleteKey	√	only 32bit keys	only 32bit keys
RegDeleteKeyEx	unsupported	√	√

√ – will run fine as it is intended.

On a 64bit Windows, always call RegDeleteKeyEx. It supports both 32bit and 64bit registry keys.
Otherwise, if you don’t want to delete 64bit keys:
- Call RegDeleteKeyEx on Vista or newer, though.
- Call RegDeleteKey on XP 32bit.

As a conclusion, you cannot use the TRegistry method DeleteKey with 64bit registry keys. Either you have to use your own RegDeleteKeyEx call or just use a derived class of TRegistry. Of course this is only necessary it you want to access 64bit keys…this article is FYI.

In the end, the question arises to me why RegDeleteKey does not support 64bit registry keys. I couldn’t find any evidences, so I can only use my brain to think of one:
Well, the RegDeleteKey function can be really dangerous if a 32bit application, that is not aware of 64bit, erases 64bit keys. This is especially true for “HKEY_LOCAL_MACHINE\SOFTWARE” because you may have installed two versions of an application with same name. First you installed a 32bit only application (name it X) you bought several years ago for your 32bit Windows. One day the vendor sends you a 64bit only update that you install (*so happy*). You decide to abandon the 32bit version and call its custom made uninstaller which deletes all of its known keys. Of course, it will also delete the 64bit version. This may be fictional but possible without the breakup of 32bit and 64bit keys in heavily used parts of the registry. So RegDeleteKey will not delete the 64bit keys because that would break 64bit applications. It seems to me that Microsoft experienced it already, before they decided to add 32-64bit registry separation. Maybe Raymond Chen would say something like this: Believe us, we tried the other way around: it’s worse.

If you are interested in more information, I suggest you to read Accessing an Alternate Registry View.

* The key was a subkey from “HKEY_LOCAL_MACHINE\SOFTWARE”. In 64bit Windows, a 32bit application (not aware of 64bit) will only see the contents of “HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node”.

Update

I submitted a bug report to QC: #87323

The Case of The Failed Loading of The User Profile

Christian Wimmer — Mon, 20 Jul 2009 20:52:45 +0000

Some time ago, I was in the situation to set up a new computer with a Windows XP 64 CD. Well it doesn’t matter that it was 64bit. However, I always create a separate partitions for Windows XP. And because user profiles tend to get big, I moved a new user to a second partition. (See the Internet how it is done) But as if it wasn’t enough I thought that I also could move the Administrator profile that easy. Way wrong!

First of all, copying a loaded user profile isn’t possible without the BACKUP privilege. You can’t open already opened files a second time (share deny). The solution is: Either you can use a backup application that runs with the special privilege or you can just use another administrative user (which I did).

There are some keys which have absolute path variables that must be changed, too. But that is a minor problem. The big problem was that Windows could not load the profile of the Administrator. Windows tried to start up the users desktop but then failed with the dialog: “Windows failed to load user profile.”

It got more confusing because every other user in the system didn’t suffer from this problem. And to top it, sometimes I could successfully login to the Administrator account.

Solution

In such cases the event manager is a good way to find the error source. In my case, it told me that “NTUSER.DAT” (this is where Windows stores the current user keys called a registry hive) was already opened by another process. I really can’t say why this was the case because it shouldn’t be the case shortly after a fresh boot up. (Of course, the file was correct, it had no write protection, and security was set accordingly)

In such a case you usually have some ways to fix the problem:

1. Reinstall Windows
Good choice. But too much work — and who will promise me that it won’t happen again?

2. Leave Administrator where it was
Also good choice. And I tried it. However my Windows could not handle two profile places somehow and the very same error occured with the old profile location.

3. Live with the situation
Some people do it. I thought about it, too, I have to admit. That’s because there is a user called root in the system now.

4. Find the bug and ignore how much time it will cost.
Ouch. I don’t have time, so not a good option.

5.Create a workaround.
YES! That’s what I did.

So I came up with a practical and fast solution. As I’ve already written, the user’s registry hive could not be loaded.
Why? I don’t know much about it but the registry file was blocked.
Well, I’ve found out that if the Administrator registry hive was already loaded (HKEY_USERS\S-1-5-21-xxx-500 is visible) the Windows could successfully logon the Administrator. I simulated this situation by manually loading the user’s profile using the LoadUserProfile function from Windows API. Well, it always worked!

uses
JwaWindows,
JwsclToken,
jwscltypes;

var
T : TJwSecurityToken;
ProfileInfo : TJwProfileInfo;
begin
T := TJwSecurityToken.CreateTokenByProcess(0, TOKEN_ALL_ACCESS);
try
T.LoadUserProfile(ProfileInfo, []);
finally
T.Free;
end;

The next step was to do it automatically before an Administrator could logon. Of course, I could have created a service which loads the user profile at startup but I wanted to be fast so there is another option called Task Scheduler.
Every Windows startup I let run the code above as a simple task with Administrator credentials (needs password).

I don’t know whether the Task Scheduler loads the profile (I would guess so). However the problem is that the profile could be unloaded after the process has ended. So the hive would be removed and logon would no more be possible.

Thus the code above just loads the profile but does not unload it. Since profiles are not watched by Windows (at least in XP) the registry hive stays loaded and a logon attempt will work (T.Free won’t unload it!).

JEDI Windows Security Code Library used features

TJwSecurityToken (class)
TJwSecurityToken.LoadUserProfile (method)

Using Windows Contacts

Christian Wimmer — Tue, 08 Apr 2008 22:17:13 +0000

Since Windows Vista, a new API called Windows Contacts (WC) was born. It replaces the Windows Address BookAPI.

You can get your personal properties by using the Windows Address Book Editor. It can be opened using “wab” in command line.

At first you see your personal “Contacts” folder. This folder contains your personal contact file. Its extension is “.contact”. A double click on it opens the Address editor as seen below:

“Web.exe” can also receive any personal contact file to import it to your personal contacts.

The contact file contains a formatted text in xml syntax. Data is arranged in a tree that is used to retrieve values. When I am writing of a path, I iterate through the tree. Some of the elements contains a collection of the same element type. The reason comes from the fact, that several other contacts can be added to the personal contact. The WC API uses the array brackets to access different contact values.

The following sample path shows you how to obtain the first user’s name.(Notice that the array starts with one not zero.)

NameCollection/Name[1]/GivenName

XML (manually formatted):

>
c:ElementID="cf809c84-6692-404e-9f57-6f81e130ee11">
c:Version="1" c:ModificationDate="2008-03-27T20:29:18Z">TestUser>
>TestUser>
>
>

This parts can be cut into three parts:

NameCollection defines a container for the array
/Name defines an array which contains all contacts
GivenName defines a name property of exact one contact.

There are also Value tags:

ContactIDCollection/ContactID[1]/Value

XML (manually formatted):

>
c:ElementID="aa8014fe-423c-4e8e-ad9f-4d750a6ba8bb">
>5634564e-72356-339-8220-12342f4a4106>
>
>

This path returns the GUID of contact number one.

Many parts of a path are already defined as constants. Have a look at them in MSDN.

So how can we read from the personal contact file? Since new API uses COM, we will use the following interfaces

IContact
IContactCollection
IContactManager
IContactProperties
IContactPropertyCollection

Actually there is no implementation of these interfaces for Delphi. To create your own type library (TLB) do the following steps (in Vista of course):

Get Visual Studio 200x
Download and install the latest version Windows SDK for Vista for MIDL and IContact.IDL.
Open the Visual Studio Command Prompt (in VS open menu Tools). We need the predefined include path settings.
Add path of midl.exe from the Windows SDK to your path environment. Use this command:
set path=%path%;\Microsoft SDKs\Windows\v6.0\Bin
Change folder to ;\Microsoft SDKs\Windows\v6.0\Include
Backup and open IContact.idl in your favorite text editor.
Find these lines…

interface IContactPropertyCollection;
interface IContactCollection;

…and add :

interface IContactProperties;
interface IContactPropertyCollection;

Additionally find this method…

HRESULT CommitChanges([in] DWORD dwCommitFlags);

…and also add :

HRESULT _DO_NOT_USE1([in] IContactProperties* pC);
HRESULT _DO_NOT_USE2([in] IContactPropertyCollection* pC);

In this way midl.exe will also create interfaces in the typelibrary for IContactProperties and IContactPropertyCollection.
I could not figure out how to do it in another way. Comments are apreciated.
You should also find all appearances of…
procedure Next; safecall;

…and replace them by:

function Next : HRESULT; stdcall;

It is necessary because we need to check for a positive return value (S_FALSE). Delphi does not raise an EOleSysError exception for positive values.
Save your work and start the conversion:
midl icontact.idl /tlb icontact.tlb
The new tlb file can now be imported using Delphi. To do so, start Delphi as Administrator, open menu “Components” and select “Install components” and hit the next button until all the components are listed. Click button “add” and choose the newly created IContact.tlb. Delphi imports the library and also generates the Delphi type library source code.

Did you know?

You can also (un)register a TLB file using regtlib.exe from C:\Windows\System32\URTTEMP
Type “regtlib Icontact.tlb” to register the library and “regtlib /u IContact.tlb” to unregister it.

You can find an already generated type library and and Delphi source code at the end of this article.

Using the Windows Contact API is really easy as soon as the Delphi type library unit exists. It implements class factories for IContact and IContactManager. Use the IContact class factory if you want to add your own contacts to the user’s personal database. If you just want to read data you have to use IContactManager.
Retrieving the current user’s profile is simple:

var
ContactManager : IContactManager;
Contact : IContact;
begin
CoInitialize(nil);

ContactManager := CoContactManager.Create;
ContactManager.Initialize(‘Your AppName’,‘AppVersion’);

These lines creates an empty contact manager. Notice that the method Initialize is necessary for further calls.
Now we have to actually open the current user’s contact database.

ContactManager.GetMeContact(Contact);

The new interface Contact contains all the user’s personal data. We can obtain it through a path value as shown in the beginning of this article.
Let us obtain the user’s name. This task is done by retrieving the property interface IContactProperties using the Contact instance.

var
ContactProp : IContactProperties;
Path,
Name : WideString;
wName : PWideChar;
Size : Cardinal;
begin
OleCheck(Contact.QueryInterface(IID_IContactProperties, ContactProp));

The new instance ContactProp allows us to access a property through a path.

…
Path := ‘NameCollection/Name[1]/GivenName’;
Size := 0;

try
ContactProp.GetString(PWideChar(Path), 0, nil, 0, Size);
except
GetMem(Name, Size*sizeof(WideChar));
ContactProp.GetString(PWideChar(Path), 0, wName, Size, Size);
Name := WideString(wName);
FreeMem(wName);
end;

The variable Name will contain the user’s name. In this way we make sure that the right amount of memory is allocated. Notice that the GetString actually returns the count of chars and not the count of bytes, so we have to double the size. We always get an exception in GetString because Delphi wraps (safecall convetion) the method and automatically raises an exception if the function returns a negative value (E_XXX code). We don’t distinguish between a memory error which we need to check for the correct size and a real error. So let us implement it in the right way:

…
try
ContactProp.GetString(PWideChar(Path), 0, nil, 0, Size);
except
on E : EOleSysError do
begin
if (ResultCode(E.ErrorCode) <> ERROR_INSUFFICIENT_BUFFER) then
raise;
….
end;
end;

In this way all “real” errors are catched and reraised.

All the other properties can be obtained in similar ways. However what properties are available at all? The interface IContactPropertyCollection allows us to obtain all available property names and types. IContactProperties implements a method GetPropertyCollection which returns a pointer to a IContactPropertyCollection that contains the requested properties. It is also possible to filter some of them.

function GetCollection(const ContactProp: IContactProperties) …
var
Dummy : PWideChar;
Props : IContactPropertyCollection;
H : HRESULT;

begin
Dummy := nil;

ContactProp.GetPropertyCollection(Props, 0, nil, 0, Dummy, Integer(true));

The new property collection contains an enumeration method to iterating all available properties. Be aware that you must call Next before you start getting data.

Dummy
ContactProp.GetPropertyCollection(Props, 0, nil, 0, Dummy, Integer(true));
H := Props.Next;

while H <> S_FALSE do
begin
…
H := Props.Next;
end;

In this way we can obtain name, type , version, modification time and ID of a property. Just use the available methods of IContactPropertyCollection.

GetPropertyName
GetPropertyType
GetPropertyVersion
GetPropertyModificationDate
GetPropertyArrayElementID

We already coded how to get a string using COM methods. So this code isn’t new to you. It retrieves the name of the property.

var
PW : PWideChar;
Name : WideString;
Size : Cardinal;
begin
Size := 0;
try
Props.GetPropertyName(nil,0, Size);
except
on E : EOleSysError do
begin
if (ResultCode(E.ErrorCode) <> ERROR_INSUFFICIENT_BUFFER) then
raise;

GetMem(PW, (Size+1)*sizeof(WideChar));
Props.GetPropertyName(PW, Size, Size);
Name := WideString(PW);
end;
end;
end;

To make life easier I created a unit that implements the shown code. You can download ContactMisc.pas in the download section of this article. The unit implements the following functions:

const
CGD_DEFAULT = $00000000;

CGD_UNKNOWN_PROPERTY = $00000000;
CGD_STRING_PROPERTY = $00000001;
CGD_DATE_PROPERTY = $00000002;
CGD_BINARY_PROPERTY = $00000004;
CGD_ARRAY_NODE = $00000008;

type TWideStringArray = array of WideString;

{@Name contains contact information}
TContactProperty = record
//ID contains the contact’s guid as a string
ID,
//Name contains the contanct’s name
Name : WideString;
//Type contains contact type
Typ,
Version : Cardinal;
Time : TFileTime;
end;

TContactPropertyArray = array of TContactProperty;

{@Name returns a contact value in binary form.
@param(Contact defines an interface to a contact which is used to retrieve data)
@param(Path defines a path to the value to be retrieved.
Most calls to @Name needs the string "/Value" at the end for success.
For more about possible path values visit:
http://msdn2.microsoft.com/en-us/library/ms735869(VS.85).aspx
)
@param(Mime returns the mime type of binary data)
@return(Returns a memory stream containing the data)
@raises(EPathNotFound will be raised if parameter Path could not be found.)
}
function GetContactBinaryValue(const Contact : IContact;const Path : WideString;
out Mime : WideString) : TMemoryStream;

{@Name returns an array of available contact properties.
@param(Contact defines an interface to a contact which is used to retrieve data)
}
function GetUserContactProperties(const Contact : IContact) : TContactPropertyArray;

{@Name returns all available contacts from a contact manager.
@param(Manager defines an interface to a contact manager interface)
@return(Returns a list of IContact interfaces)
}
function GetContactList(const Manager : IContactManager) : TInterfaceList;

{@Name returns the value of a contact’s property
@param(Path defines a path to the value to be retrieved.
Most calls to @Name needs the string "/Value" at the end for success.
For more about possible path values visit:
http://msdn2.microsoft.com/en-us/library/ms735869(VS.85).aspx
)
@param(Contact defines an interface to a contact which is used to retrieve data.)
@raises(EPathNotFound will be raised if parameter Path could not be found.)
}
function GetContactValue(const Contact : IContact;const Path : WideString) : WideString;

Some hints in the end

The Windows Contacts API does not allow to open foreign contact profiles. Although IContactManager implements the method Load, it is useless. Every contact file may contain several contacts. However only one contact belongs to the user. The method Loads expects a contact file name and the user’s ID (GUID) . /GUID:”xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx” /PATH:”……..\xy.contact”
You cannot retrieve the GUID of a foreign user with the WC API. To do so, you had to parse the contact file manually.
So how does
ContactManager.GetMeContact(Contact);

retrieve the user’s ID?
The ID is stored in the registry. Look at …
HKEY_CURRENT_USER\Software\Microsoft\WAB\Me
…and you’ll find the a string that is necessary for the Load method of IContactManager.
The WC API is sensible to the current token. A service may use an impersonated thread to get a foreign user contact.

Download:

Download the package here. It contains:

IContact.tlb – type library
Contact_tlb.pas – delphi type library header
ContactMisc.pas – IContact tools
Contacts.dpr – small demonstration