Powershell Studio - Check Registry - Windows 8 Issue

[jvierra]

Buiold your form using teh 64 bit version of PowerSWHell and target a 64 bit forms version.

If you run under the ddebugger you will not see the registry.

You should put the values in teh 32 bit registry if you want one version of the script to run on all platforms or chack the architecture and pick the correct registry at runtime.

Using the defaults puts teh values in the platform native version. 32 bit for 32 bit machines and 64 bit for 64 bit machines.

If you run 32 bit on a 64 bit machine you will nOT be able to see the 64 bit registry. Running 64 bit you can see both registries.

Now tell me you understand.

Don't worry. Not even Mic5rosoft can explain this.

Start by understanding that there are two registries on a 64 bit OS.

[jvierra]

Here is a starter.
http://msdn.microsoft.com/en-us/library ... s.85).aspx

This will give you the basics.

What version of forms did you generate for. Gen for 64 bits and your keys will be available.

You need to think how you will distribute and maintain you script in a dual environment.

[jvierra]

Here is an example of how to read the 64 bit registry from a 32 bit process.

http://gallery.technet.microsoft.com/60 ... f18c8324c0

[galaara98]

I just simulated your issue and I cannot recreate it.
On Windows 8 Ent Edition, 64bit
Using Explorer (WINDOWSKEY-R -> regedit [ENTER])
I launched a 64bit registry editing tool

Using Regedit
> I created a registry key HKLM/Software/Test
> I created a String Value
> with the name of:Test
> and Data of:yes

Using Windows Powershell ISE, (WindowsKey-E -> C:\Windows\System32\WindowsPowerShell\v1.0\powershell_ise.exe) a 64bit PS Interpreter

I Created a blank ps1 (File menu -> New)
I Pasted your code
I saved the file to my desktop
I set a breakpoint at the first line
I ran the Code (f5)
I stepped one line (f11)

using the mouse to interrogate the value of $key I already knew I was able to see the previously set registry. Further more $key returns "yes" to the console.

I let the code finish, I received an error because $textbox1 was undefined (expected result), while in the first half of your if (the branch that is dictated by ($key -eq "yes")

So I cannot reproduce your results.

Aaron

However, the point jvierra is trying to make is your issue demonstrates the powershell you personally are executing is running as 32bit... or you wouldn't be having this issue
If you had used a 32 bit program to SET the value (like 32 bit regedit, you also would not be having this issue...)
However you used a 64bit aware binary to set the value, and based on your results, you are using a 32bit binary to query the value.

Aaron

My advice, if at all possible either do everything 64 bit (that way the 32 bit redirection mechanism doesn't confuse you and what you see is what you get) OR if that is not possible, learn how to simulate a 32 bit world by launching system tools from C:\Windows\SysWow64... like cmd, regedit, odbc config tools, etc. So you can understand how your 32 bit apps see the world, how files and registry locations are "redirected" for backwards compatibility, etc.

Aaron

[jvierra]

Aaron - Now run the 32bit version ort PowerSHell and look for the key. YOu won't see it.

The forem can be packaged at 32 bit and it will not be able to see 64 bit keys. Th e OP is most likely using a pqackeged form or project set to 32 bits.

Yes use the 32 bit reg utility and create teh keys in the SYSWOW but that will not help on a 32 bit platform becuse at 64 we must retrieve a differnt path. WMI resolves this because we can ask for eather regiostry no matter what architecture we are running.

There is no reflectiopn in Windows 7 and later. It has been removed in favor of shared keys. HKCR is a shared key. Write to and read either they are always the same. Reqad teh links I posted to understand how this works.

It is not as simple as you think it is. It takes a while to get an understanding of how this has been implemented WIn 7 and later.

[galaara98]

if he has used a 32 bit binary to set the data, it would have in fact set HKLM/Software/Wow6432Node/Test

You can validate this by running 32 bit regedit (C:\windows\sysWOW64\regedit.exe) which cannot see the 64bit registry tree. Then create a value at HKLM/Software/Test

Now open 64bit regedit (C:\windows\system32\regedit.exe) and you will notice that the value is in fact written to HKLM\Software\Wow6432Node\Test

We are actually discussing the same thing. I am merely pointing out that based on his results he used a 64bit binary to set the value, but used a 32bit binary to attempt to read it.

You can use a 32bit binary to read the 64bit registry through WMI, however I would propose that it would be better to start using a true 64bit binary or if that is not feasible learn how to use 32 bit system tools so you can understand what 32 bit programs see..

I can tell you right now 32 bit redirection is alive and well. Open 32 bit notepad (C:\Windows\syswow64\notepad.exe)
save a file to C:\windows\system32

Now go find that file with 64 explorer (your desktop)

You will find it was written to C:\windows\sysWow64\ instead [tricky little Microsoft lied to the 32bit program... naughty]

Yes portions of the OS and registry are shared, but portions are 'redirected' It is helpful to understand when and where it happens, so I recommend to people to run 32 bit notepad and 32 regedit to better grasp when the OS is lying to them.

Aaron
(or always stay in 64 bit, then you are in control of both the 64 bit and 32 bit worlds, as they appear separate to you... I am a big fan of control... If I were him, I'd compile his forms in 64 bit, but I'd check for the existence of the value in BOTH the 64bit and 32bit registry trees, preferring the 64bit and only throwing an error if both locations are invalid... that way, the program is never confused)

[jvierra]

Ok - your first post wasn't clear to me.

Like I posted. It is easy to get confused because there is not good language construct that works for someone who doesn't already understand.

[adam.gallenti]

Thanks Guys,

It is now working, I realized there were two registry's, I just thought because I specifically specified a location, it would look there rather than under wow6432Node.

Adam

[jvierra]

He said carefully.

Stephen Dedalus couldn't have said it better....

The first time it gets everybody so don't think it is just you being picked on.