Registry.getStringValue() fails on Thinkpad machines

[sengsational]

I’ve replicated Everett’s issue. In both his and my cases it’s limited to Java on Thinkpads and it evidently arose in the last month or so. I’ve run ServiceLauncher.java in the Eclipse debugger and set a breakpoint at line 67:

String registryFolder = Registry.getStringValue("HKEY_LOCAL_MACHINE", "SOFTWARE\\Silicondust\\HDHomeRun", "InstallDir");

Sure enough, stepping to line 68 shows: registryFolder null

Evidently, some recent update to Everett’s and my Thinkpads has screwed up Java’s Registry access somehow. Is there an alternative method to read from the Registry? I guess the good thing is that not many are likely to be running CW_EPG on a Thinkpad!

[sengsational]

This appears to be an issue with the JVM. Nothing to do in the code, so I'm closing this.

[sengsational]

@TPeterson94070 Could your machine have entered the same state as Everett's?

[sengsational]

Putting "Java StdCallLibrary reading windows registry failing" into Google has some suggestions for why this might be something we can fix on our side.

We could try:

• Running CwHelper as administrator and see if that helps
• Figure out how to read 32 bit vs 64 bit with the current Advapi32.java or
• Update Advapi32.java (the one we have is probably a decade old)

[sengsational]

I just uploaded 1082 which might solve the registry read problems we've been having. It was a quick fix that added ASCII registry access (was strictly UNICODE before). So it might now do both. It still reads the registry on my HTPC.

I got the code from here: https://github.com/java-native-access/jna/blob/master/src/com/sun/jna/win32/W32APIOptions.java

What we had was Options.java that always used UNICODE_OPTIONS, and this checks "w32.ascii" and if true, returns ASCII instead of UNICODE.

b8d73ce

[sengsational]

The small change in b8d73ce did not correct the registry reading problem on an affected machine, so I reversed that with 2b5b37c .

At some point, we probably should revisit the registry read problem, but since we have a work-around, it's not high priority. It would take some dedication for testing since it doesn't happen in my environment.