32 bit program on 64 bit OS, the Active setup registry keys

There is a whwole lot of confusion on the 3X2 matrix of hardware, OS, Application runnig on 32 bit and 64 bit OS.
So i clarify the newbies things first and then move on to explain an interesting thing that I 'discovered' about the title of this post.

1. Machine can be X86 or X64. When someone tells you that he bought an x64 machine, hear it as 'i bought a machine with x64 processor'.
2. OS (windows) comes in two forms in terms of architecture. the primary target is an 64 bit windows for x64 machine and a 32 bit windows for x86 machine, but there is a small catch here. A 32 bit windows is installable on x64 machine. No, you wont have any truoble. Nothing at all. You won't ever know that you have an x64 hardware, unless of course you have adebugger hooked to the kernel of then machine and you are exploring the boundary of hardware and software where the hal picks it up.
But this (installing 32 bit OS on x64 machine is just a waste of the power of the machine. I wouldn't be able to allow you the previlege of the x64 architecture)
3. Applications are written seperately for x64 and x86 machine. Visual studio has the default configuration of making the binary architecture independent, but you can change it to x86 or x64 specifically. Now an x86 application will run on both x86 and x64 machine, but an x64 application will run only on x64 machine and not on x86 machine. (By machine here I mean OS. 32 bit OS on x64 machine = 32 bit machine, 64 bit OS on 32 bit mahchine = you are a fool, it doesn't exist).

Now let us move to the topic of the blog here:
Suppose I am writing an application which has both 64 bit and 32 bit versions like Internet Explorer. On a 64 bit OS, it exists as C:\program files\internet explorer\iexplore.exe which launches the 64 bit instance of IE and c:\program files(x86)internet explorer\iexplore.exe which launches the 32 bit version of the internet explorer.
Now, suppose the application contains the set up part.
In the setup part you will have to add some regkeys so that when any new user logs in he gets the personalized settings for that application. You would have noticed that when a new user logs in, a window comes up on top right corner stating something like "personnalising settings" and vanishes very soon.
For 32 bit applications on 32 bit OS these keys are created under the regkey:
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup"
For 64 bit applications on 64 bit OS these keys are created under:
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup"

But the situation of 32 bit apps on 64 bit OS is little different.
For them all the calls are redirected to 6432 node in registry.
Thus these settings get created in
"HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Active Setup"

Now on a new user logon on 64 bit OS,
explorer.exe of windows reads the keys under "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup" and as per the settings there, the personalization of settings by the application is run.
What about the 6432 node in which the 32 bit apps on 64 bit OS store their active set up?
Well, it never gets read by the OS and is never execute. lo! and behold! That is a bit problem.
Here are three workaround:
1. Login as any user and kill the explorer "taskkill -f -im explorer.exe". Restart the explorer from c:\windows\syswow64\explorer.exe. This is the 32 bit explorer.exe on the system which is always present but by default only the 64 bit explorer.exe at c:\windows\explorer.exe is run.
Since the explorer.exe now running will be 32 bit one, it will read the keys under
"HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Active Setup" and execute the settings there. But this is not a supported scenario, so cannot be trusted to let other things work well. There will definitely be problems related to control panel applets and file path redirections
2. Register you application in the 64 bit node. This can be done by setting the flag "msidbComponentAttributes64bit" at http://msdn.microsoft.com/en-us/library/aa368007(VS.85).aspx.
This will mark the component as a 64 bit one and you will 'fool' the OS into believing that it is a 64 bit application. But since this is applicable only for the active setup part, apart from small file redirections in the part of your app which deals with active setup, you dont need to be careful anywhere else.
Also settings this flag will create the registry entries at
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup" which is actually the place for 64 bit apps only.

The above explanation is valid only for Win2000/WinXp/Win2003. From Vista and above it is a little different.
in vista, the 64 bit explorer will run both the 32 bit active setup part (wow6432 node) from the registry as well as the 64 bit part. The order will be 32 bit first and 64 bit next.
So if your app has both 64 bit and 32 bit part and both of them register their active setup (like IE), the 64 bit settings will take precedence. So you dont need to change anything in your app if it is 32 bit only or 64 bit only, but if it ships as both of them, better make the things explicit to the customers (and developers).

Here is how the active set up keys actually work:
When a user logs in , the contents of this active setup key is compared against the SAME key in HKCU. If the HKCU key does not exist and/or the "version" value is less than that in HLKM, the appropriate "StubPath" command is run and the key copied to HKCU so it is not run again.



To see how this works for yourself, you can create a key in HKLM…Installed Components and call it "test". Then, add to it a String Value "StubPath" and set it to "notepad". Reboot. See that when you log in, notepad starts. Log in as a different user. See that notepad starts. Log in again with the first ID – notice notepad does not start – as now the "test" key has been copied into the HKCU branch after it ran the first time. Note that version is not necessary.


This way the settings can be personalized for each user login.

Send a mail to sidscrazy@gmail.com in case there is some doubt that you would like to clarify

Debugging Windows

Many times my friends ask, how do we debug windows.
You must have debugged your own code many times.(People from non-coding community are not welcome to this blog). All you do is launch the exe in debug mode in visual studio or gdb , put a breakpoint on the concerned place which you doubt the most to be flunking, and the execution stops right at that place.
But then, think if I do the same to windows. Windows stops!!Whoaa!!! Do you understand what does this mean. Even your visual studio stops because it is working 'above' windows.
Add to that the fact that this windows is millions of lines of code. Guess which function you would put the breakpoint on, if a particular file deletion process is not working fine. Since, there are thousands of project running in millions, I wouldn't delve into how such things and debugging them is managed(through componentization).

Windbg is a very common tools for people debugging, understanding, troubleshooting and hacking windows.
This is a very handy and useful tool to debug any application, where you cannot use the conventinal method of debugging. There is a code project article which can be useful for beginners and budding hackers to understand what exactly goes on while you are clicking a mouse button in windows.

The most common complaint of windows users is their 'view'(actually explorer.exe, Ok, budding technocrats who are yet not comfortable with tech terminologies are welcome here :p) hangs. Or the crash where you get the option of "send" or "don't send" and most of the time you click "don't send". Well this is actually the watson window crash. When you decide to send it, the 'state' of your machine is sent to Microsoft where engineers are engaged to find out why it happened so that this can be corrected in the next product cycle.

But this might also happen when there is a third party (non-MS) software installed on the machine. Or there could be a virus which is screwing up your machine. If you know that you are getting this window very often, the best thing to do is
1. 'Attach' debugger to the process or service which you think might be screwing it up.
2. Continue with your normal operation
3. The moment there is a crash, ie, the ugly watson window is about to come up, the process will 'break' into debugger and you can now 'watch' it. You can also see what happened
4. Hit 'k' command in debugger to see the stack trace and know which binary is flunking.

If you get a windows binary in top of stack and doubt that windows is screwing you , you can download the public symbols. More information is found here. Information about how to configure the debugger(windbg as well as any other debugger) is found here.

All that I have said above is valid only for user mode debugging. For kernel mode debugging, needed for developers writing drivers, file systems or implementing their networking wrappers you need two machines. The debugee having a com-port and a debugger where you will have the windbg and symbols. You will need a COM cable to connect the machines.
After that once the debugger is able to connect to the debugee, you can virtually move through all the kernel mode objects, handle tables, thread switching, memory allocation data structures. The driver you are writing can be debugged here.

Unlocker

How many times have you come across messages like "Cannot delete file. it is being used by another person or program. Close any program that might be using this file and try again". This is a safety precaution of OS, more specifically explorer to 'lock' a file while a critical section is is accessing this file.

This software which can be downloaded from here is very useful in negating such things.
For example consider a file move operation on Windows. Following are the events which actually take place:
1. Source and destination are taken by the OS
2. A backup of the source file is created.
3. The move process starts and the destination starts getting created.
4. If the the process is aborted, the destination file is deleted and the backup file is placed in the source place.
5. If the process completes, the backup for source file is deleted and the destination file is created.

During the time when the process isexecuting, both the source and dstination file are 'locked' by explorer. This is to prevent any anomaly or integrity defect. Imagine yourself changing a file which is being moved. What should be the destination, the one which existed initially or the one which you created after your modification process?

The unlocking option is created as a context menu in explorer , visible on right click of the file/folder. This probably is acting as a hook into the explorer.exe process. It can also kill process, close open handles to a file and unload dlls.
All in all this is a very useful utility if you are doing very file intensive operations on the machine and frequently run into the problems where you run into problems mentioned above.
The usage is strictly discouraged just unless you encounter the problems mentioned as it changes the basic, default functionality of OS. In case you are dealing with critical files, which don't have back up, please dont use it. Since it is unlocking the files, there is (very small) probability that the file may become corrupted and you may not be able to recover.
All in all this utility targets one of the most common problems of Windows and solves it very nicely.
Cheers to unlocker.