Editing Registry With VB - vb.net

I'm just familiarising myself to edit registry in VB. I am having a problem with changing a value in the HKEY_LOCAL_MACHINE key. When ever I change a value at runtime it always assumes that I am going in the "Wow6432Node" key, even though I don't put that in the parenthesis. Example: My.Computer.Registry.SetValue("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Folder\Hidden\SHOWALL", "CheckedValue", 1)
and it doesn't change the value in the string above, but changes it as if I have put "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Folder\Hidden\SHOWALL" in the string.
The program is running as administrator.

That's called registry redirection. In 64 bit Windows some registry keys (including HKLM\Software) are redirected for 32 bit applications. If you changed the build properties on your VB.NET project to x64 you would see it write to HKLM\Software. You can access the non-redirected keys using flags, but I believe those are only available for the unmanaged APIs.
But the short answer is you not doing anything wrong, and that how it is supposed to work.

Related

Firebreath plugin not loading in IE 10

EDIT: See end of post for more information.
I am trying to to get plugins created via the Firebreath framework (1.7.0) to load. I am on Windows 8 in Desktop Mode using Internet Explorer 10. I've reproduced this with the built-in test FBTtestPlugin that comes with Firebreath. The failure is silent in that the object element is created, but fails to have any properties specified by the plugin. How does one go about debugging this? The Microsoft Internet Explorer Compatibility Tool reports that the plugin is failing to load.
(The FBTtestPlugin loads three plugins, hence the three errors.)
I've got other (non-FB) plugins working on the same settings (e.g. the example here: http://msdn.microsoft.com/en-us/library/dd565667(v=vs.85).aspx works fine as do all the examples from this site http://ie.microsoft.com/testdrive/browser/activexfiltering/Default.html ).
I've tried a huge combination of security settings, but here's the most relaxed set I have so far follows:
Tools / Safety / ActiveX Filtering: is unchecked
Internet Options / Security / Internet: "Enable Protected Mode" is unchecked
Internet Options / Security / Internet: is at Custom Level. Under ActiveX everything is "enabled" except restrictive properties such as "Allow ActiveX Filtering"
All sorts of security warnings are visible based on these settings.
Note: I don't intend to keep these settings. I just want to get the plugin working, then work backwards re-enabling security settings.
UPDATE
I figured this out partly and can now run the FB test FBTestPlugin. To make debugging easier for IE, I defined the registry key HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\TabProcGrowth as 0 to limit the browser to use one process. Unfortunately, with IE10 both iexplore.exe in Program Files and Program Files (x86) direct to the 64-bit version of IE. This prevents 32-bit plugins from running (see http://support.microsoft.com/kb/2716529 ), and the symptom is silent failure.
However, my plugin still fails to load in IE and the retitled question above is otherwise still open. The problem is still silent load failure. However, I think it may have something to do with plugin configuration. The CLSID listed in the Compatibility Test Tool (like the example shown above) is listed as all 0's instead of a valid GUID. Moreover the registry looks funky: The key HKCR\Company.Name exists as does HKCR\Company.Name.1, but both are empty (instead of having a CLSID child as in normally working plugins). The expected GUID does exist, but under a bogus name "applications.'". I am now digging into the code that gets called when regsvr32 is run.
Thanks all!
I am providing this answer in the hopes that someone can use the result.
IE was not loading the plugin for two reasons.
1) The TabProcGrowth registry key and the 32/64 bit issue with IE 10. ( http://support.microsoft.com/kb/2716529 )
Don't define this key.
2) My plugin description used an apostrophe (e.g. "Gluttco's Plugin") and this messed up the registration of the component.
DETAILS ON 2):
I traced through the DllRegisterServer code and found that the phoney registry entries are due to the fact that my plugin description contained an apostrophe. E.g. "Joe's plugin". The generator (fbgen.py/cmake), generated a malformed FBControls.rgs file (it't didn't escape the quotes and thus contained a string literal such as (s 'Joe's cool plugin'). The DllRegisterServer code (called from regsvr32) used the contents of this file (embedded?) when (deep in atlbase.h). Oddly, the parser did not detect the error (or somehow erroneously recovered). From Process Monitor I could see a bunch of bogus keys being added, before it started adding good registry keys again.
For now Firebreath plugin descriptions should not contain apostrophes (probably other characters are illegal too). It might be sensible to make fbgen.py check for these characters and possibly escape, reject, or replace them.
Searching found this: http://msdn.microsoft.com/en-us/library/dd565667(v=vs.85).aspx
Do you have any group policies in place that could affect it? I don't think this is related directly to FireBreath, rather to the activex configuration...
I also found http://social.technet.microsoft.com/Forums/windows/en-US/90c3202c-448b-42b7-acf7-dab8dba7b000/one-or-more-activex-controls-could-not-be-displayed-because-either which has a few things you could try.

AllowAllTrustedApps registry key not available in Windows RT

I have tried to find the registry key
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Appx\AllowAllTrustedApps
in Windows RT and it appears to be missing. I got as far as the Windows folder, but the Appx folder isn't there. Am I missing something? Does the machine need to be connected to a domain to see this part of the registry? Or can I simply add the subfolder and key and expect it to work?
It turns out that adding the key and value works.
1) Make sure the key HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Appx exists. If it doesn't, add it.
2) Make sure the 32bit DWORD HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Appx\AllowAllTrustedApps exists. If it doesn't, add it.
3) Set the value of that DWORD to 1.
4) Voila! You can now side load your Windows Store App and/or inject a custom data file without a license xml file.
http://technet.microsoft.com/en-us/library/hh824882.aspx

vb.net 2010 - reading from registry doesn't work - win 7

I thought this would be dead simple however....
Right, so all I'm simply trying to do is read a value from my registry. I have been through several examples but can't get any of them to work. I've also tried running my application in Admin mode and still nothing. Can someone please help?
From all my examples that I've tried, I'll use the simplest one.
This works:
Dim val As String
val = Registry.LocalMachine.OpenSubKey("Hardware\Description\System\CentralProcessor\0").GetValue("Identifier").ToString()
MsgBox(val)
This (the one I want) doesn't:
Dim val As String
val = Registry.LocalMachine.OpenSubKey("SOFTWARE\PTSClient").GetValue("ConfigDB").ToString()
MsgBox(val)
THe latter path and value is one that I've manually created in the registry. I've checked the permissions between the two and they are the exact same. I've also tried running the app as administrator. I get a runtime error on the val= line, it says: Use the "new" keyword to create an object instance.
Any ideas? All the various online examples have failed and for the life of me, I can't figure out why...
Cheers,
J
Well, I have tried your code with a sample application compiled for x86 and, as expected, it fails with a null value exception.
I assume you are building an application for x86 mode and running in a 64bit environment.
Of course, if this is not the case, let me know and I will delete this answer.
In the situation outlined above, the calls to read/write in the LocalMachine.Software registry path will be automatically changed by the Operating System to read/write in the Software\Wow6432Node subkey and thus, your code is unable to find your manually inserted key ("SOFTWARE\PTSClient").
This code will give a null value as return from Registry.LocalMachine.OpenSubKey("SOFTWARE\PTSClient") leading to the failure to get the ConfigDB value.
You need to add your keys/values to the Software\Wow6432Node path or compile your application for AnyCPU mode or let your code write the value to the register (it will be redirected to the Wow6432Node).

How to find COM object given only server.create instance?

I have inherited a classic ASP application and looking through the code I see a custom COM object reference
Server.CreateObject("DBaseManager.Recordset")
Now, unfortunately looking through to source code there are no .dlls provided so therefore the COM dll must still exist on the live server.
In order to get the code working on my Dev Server I need to get a copy of the dll so I can register it on my Dev server.
Does anyone have any recommendations about how I might be able to find the COM dll that makes the above call?
Thanks and best wishes
Mark
Registry search - under HKEY_CLASSES_ROOT, locate the DBaseManager.Recordset key. Under that key, there should be a CLSID key, with a default value containing a guid.
Now, search for that guid under HKEY_CLASSES_ROOT\CLSID. There should be a subkey under that key called InprocServer32 (if it's an in-process COM library), which in turn should have a default value giving the path to the DLL.
Of course, if the DLL in question is part of a larger product or SDK, merely installing the dll on your dev server may not be sufficient. You may have to locate and install the whole product/SDK in order for it to actually work on another machine.

Can I display GUID in windbg?

I am trying to debug some COM components and want to track down CLSID and IIDs in calls to CoCreateInstance.
I am not sure how to display GUID in windbg. Any pointers for that.
Use the "display type" command:
dt GUID [address-of-guid]
For more information see the documentation.
If it is in a local variable (local to the stack frame you're in), use dv /V to dump all local variables.
I don't know anything about COM, but if this is just a normal variable (even if it's a global one), then you can always do:
alt+2 to bring up the watch window and enter the name of the variable there, eg
blahblah.dll!guid
You'll need the symbols for that, possibly need t be in source mode aswell. This is slightly nicer than dv/dt in that you don't have to type it in constantly. You can enter the address as well, I think. Note that if you don't put blahblah! then it can occasionally cause windbg to stall for a few seconds as it searches every module for something called guid.