How are the GetObject progids maintained? - windows

Windows Shell Scripting (vbs) has the following method:
object.GetObject(strPathname [,strProgID], [strPrefix])
Now suppose I have the following code:
set myval = getObject("myObjectRef:myObjectArgs")
This works on one machine - and not on another.
What I want to do is find the definitive list where all the myObjectRef/progIds are maintained.
My question is:How are the GetObject progids maintained?
Assumptions:
I'm looking for an answer more sophisticated that "do a search in the registry"
I'm looking to find a particular place where I can go looking for my progid to see if it exists or not.

I'm looking for an answer more sophisticated that "do a search in the registry"
Well, that's a bit difficult because that is really all it takes. You don't exactly have to "search", just look at where you expect it to find. Which is right underneath the HKEY_CLASSES_ROOT hive in regedit.exe, the keys are sorted alphabetically so just type the "m" key on your keyboard and you are already close the progid you are looking for. If you don't see the "myObjectRef.myObjectArgs" key then you can count on a kaboom at runtime when COM cannot find it either.
There is no "definite list" and no entity that maintains progids to ensure that they are unique. The list is specific to each machine, whatever was installed on that machine determines what you find back with Regedit.exe. They are simply a human-friendly version of the GUID, the value that really matters to locate a COM component. A Globally Unique ID that unambiguously identifies the server. The CLSID subkey of the progid key provides that GUID. It is a big number, not very human-friendly.
The progid key is written to the registry when the component installs itself. So a missing key simply means that it isn't installed.
A not uncommon problem on machines that boot a 64-bit version of Windows is that the COM server is only available as a 32-bit component but the client is a 64-bit process. This is resolved in the registry as well, the CLSID key is only present in HKLM\Software\Wow6432Node\Classes. The Wow6432Node section is what a 32-bit client sees. So a 64-bit client looks in HKLM\Software\Classes and won't find the key. Looks just like a "not-installed" problem, even though it is actually present. Just not the 64-bit version of it. SysInternals' Process Monitor is a great tool to diagnose problems like this. You see the failing client program searching through the registry.

Related

What is the purpose of OpenWithProgIds registry key?

I have read through many Stack Overflow questions as well all related Microsoft documentation I could find, however, I couldn't discover an exact answer.
I'm registering my program as a default application for a specific extension in Windows 10. I added the following entries to the registry:
HKCU\Software\Classes\my-program.ext
HKCU\Software\Classes\.ext\(Default) = my-program.ext
HKCU\Software\Classes\.ext\OpenWithProgIds\my-program.ext
Everything works fine, the association is successfully created.
However, I don't understand the purpose of the OpenWithProgIds. I thought it represents the list of alternative applications for this extension, however, even without adding my-program.ext to OpenWithProgIds my program is still present in the "Open With" list as well as all the previous applications registered through .ext\(Default).
Seems that there is some kind of cache containing all the previously associated programs for a specific extension. But if so, why do we need OpenWithProgIds at all? Probably this behavior was introduced in Windows 10, and the OpenWithProgIds is considered obsolete.
I would be grateful for any thoughts or clarifications.
According to the documentation, the purpose of the OpenWithProgIDs subkey is to provide a better experience for the user.
Excerpt:
You can register different applications that are able to open a particular file extension by adding versioned ProgIDs as values to the HKEY_CLASSES_ROOT<extension>\OpenWithProgids key. This registry key contains a list of alternate ProgIDs associated with the file extension. The applications associated with the listed ProgIDs appear in the Open With Product Name submenu. If the same application is specified in both the OpenWithList and OpenWithProgids keys, the operating system merges the duplicates.

For COM server and registry key redirection, does it need to do file path redirection translation?

Forgive me if the title is not so accurate.
I have met some problem when I am doing something related to COM server and registry redirection and not quite sure is my understanding is correct or not. Hoping anyone could share some light on it. Thanks in advance.
Basically a COM server has been registered in the registry before anyone can use its service. On a 64bit Windows OS, there could be 2 possible views in the registry table, one is for default and the other for the WOW64 view. For example, first registry key is: COMPUTER\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID{GUID}\LocalServer32 and the other is: COMPUTER\HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID{GUID}\LocalServer32.
And depends on the process bitness (64bit vs. 32bit) that either one can be read by default, and also we can use KEY_WOW64_64KEY or KEY_WOW64_32KEY (as: http://msdn.microsoft.com/en-us/library/windows/desktop/aa384129(v=vs.85).aspx) to access the other alternative registry key.
What I need is that, I want to get the LocalServer32 executable file by reading the registry key and this can work. The problem is that, for the executable file path I read back, do I need to do the file path translation (in order to get the correct value) depending on which view I get the value from? For example, if the file path is got from COMPUTER\HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID{GUID}\LocalServer32 and the file path is: C:\Windows\System32\abc.exe, do I need to translate the path to: C:\Windows\SysWow64\abc.exe? Or do I need to translate C:\Program Files\abc.exe to C:\Program Files(x86).exe?
Another question is that, if, for some registry key for COM, the values set in the two Views are different (for example, one has C:\Program Files\abc.exe and the other has C:\Program Files(x86)\abc.exe), then when the COM server is started, how could svchost.exe know which one to start, C:\Program Files\abc.exe or C:\Program Files(x86)\abc.exe? Does anyone know the logic for svchost.exe to determine this? Use the first one if it exists otherwise use the second one?
Thanks a lot.
A 64-bit version of Windows already has all the features in place to make it unnecessary for you to take care of it yourself. You just need to keep the rules in mind when you troubleshoot problems.
First is the registry redirector, it ensures that a 32-bit client program cannot accidentally read keys that contain configuration information that's only appropriate for 64-bit programs. You already know it, most of the HKLM\Software registry accesses are redirected to HKLM\Software\Wow6432Node. This redirection is already in place when the COM server is registered, a 32-bit installer is automatically redirected to write the keys to Wow6432Node instead. The installer is completely unaware that Wow6432Node even exists. Everything falls together automatically, the installer is redirected and the COM server client is redirected as well. All that you care about is knowing where to look to verify that the install was done properly, you do have to look at HKLM\Software\Wow6432Node\Classes\CLSID with Regedit.exe to find the keys back.
File redirection works much the same way, any access to c:\windows\system32 is redirected to c:\windows\syswow64, from c:\program files to c:\program files (x86). And very similarly, a 32-bit installer doesn't have to know beans about this, it can simply use the legacy 32-bit path names. Same for any 32-bit client program, it will be redirected the same way. All that you care about is knowing where to look for a file to verify the installer.
This can only go wrong if bitness is mixed, a 64-bit program reading registry keys or files installed by a 32-bit program. Or the other way around. Like it does with your troubleshooting tools, like Explorer, Regedit and SysInternals' Process Monitor. In general something that should be strongly avoided in COM, most servers are in-process servers and running 32-bit code in a 64-bit process is not possible. The biggest reason that the registry and file redirectors exist in the first place.

How can I place data in WOW64's 32 bit registry view from the NT Native API?

I have an application where I am restricted to using the NtCreateKey / ZwCreateKey function(s). (e.g. in a driver) There is another application I don't control which runs under WOW64, which reads a value from this registry key.
I want to set the registry value such that this application can find it. However, WOW64 is implemented in kernel32 -- so I can't pass the KEY_WOW64_32KEY flag like I can when using RegOpenKeyEx.
The easiest way seems to be to include Wow6432Node in the path passed to ZwCreateKey, but MSDN discourages this:
WOW64 defines the following symbolic links only for compatibility with existing applications that may use hardcoded registry key paths containing Wow6432Node. New applications should avoid using Wow6432Node in registry key paths.
This seems to put me between a rock and a hard place... how can I place data in the 32 bit registry view? The MSDN language says "avoid" -- is this a situation where Wow6432Node is unavoidable?

Acquiring Registry Path using NtQueryObject

I need to acquire registry path by it's handle in runtime. For this, I'm using NtQueryObject function. My problem is that NtQueryObject gives me the path in strange format (see image below).
I guess, this is the kind of format you need to use when you are writing drivers, but I want to have this path converted to standard reg path, such as
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run".
Currently I'm replacing
\REGISTRY\MACHINE\etc
with
HKEY_LOCAL_MACHINE\etc
but this Wow6432Node key is a problem. I guess it's name will vary across different machines, even 32 bit windows didn't have that key there. So my question is, is there any standard way to do reg path conversion (maybe some win api does it)?
The Wow6432Node really is part of the registry path to that particular key, although it is hidden from 32-bit processes. If you look in the Software key with Regedit you will find Wow6432Node.
On 64-bit systems both HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run and HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run exist. Depending on what you are trying to do, you may need to work with both of them or only one.
This describes the registry keys affected by WOW64:
http://msdn.microsoft.com/en-us/library/aa384253%28v=VS.85%29.aspx
You can explicitly access the 32-bit or 64-bit view of the registry as described here:
http://msdn.microsoft.com/en-us/library/aa384129%28v=VS.85%29.aspx

Mysterious, Native "A" Registry Key with Path: Registry\A

I recently wrote a native NT registry editor for Windows, and ran it on Windows 7. To my surprise, in addition to the two standard root keys, MACHINE and USER, that are present on Windows XP, there was also a mysterious key named "A", that cannot be opened in any way, whether by permission changes or backup privileges or otherwise:
Does anyone know what this key is for? I don't believe it's for any software, because it was there before I installed anything on the machine, and I believe I saw it on another fresh installation as well. It's rather very suspicious, and I'm curious as to why it's there. (If I'm curious enough, I might end up writing a driver to open it up without a privilege check, to see what happens!)
(I wasn't sure whether to put this on SuperUser or StackOverflow, since I think it could go in either one. I could be wrong, though; sorry if this isn't the appropriate place.)
Edit:
If forgot to say, I don't believe you can even see this key using the Win32 API, like RegOpenKey -- you have to use the native API like NtEnumerateKey instead.
Here is the comment from one of our driver writers: "DISCACHE.sys driver seems to be caching system file attributes and using \REGISTRY\A in an undocumented way. This driver is part of the kernel so it can load any hive wherever it wants."
Interesting...
The key indeed can be opened with a relative path, but not with an absolute path.
And it seems to contain information about all file systems and whatnot. Looks mysterious, indeed...

Resources