This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 251538

Summary: Your Installer is Creating Invalid Data for the NoModify DWORD Key which crashes enumeration of the Uninstall Key in at least PowerShell
Product: installer Reporter: djsnetbeans
Component: NBIAssignee: Libor Fischmeistr <lfischmeistr>
Status: NEW ---    
Severity: normal    
Priority: P3    
Version: 8.0.2   
Hardware: PC   
OS: Windows 7   
Issue Type: DEFECT Exception Reporter:
Attachments: Registry key for NetBeans - same value is in glassfish registry key.

Description djsnetbeans 2015-03-31 17:34:55 UTC
Created attachment 152951 [details]
Registry key for NetBeans - same value is in glassfish registry key.

The information here: http://connect.microsoft.com/PowerShell/feedbackdetail/view/801007/get-itemproperty-specified-cast-is-not-valid-error-when-reg-dword-value-has-binary-data

Shows the basics.

In my environment we've seen it with NetBean 8.0 and 8.1 on PowerShell 2 and 3 on Windows 7 x64 SP1 (monthly security patches are applied).

It is in both glass fish and nbi keys - so I'm thinking it may be a problem with how all your installers are coded.

It is a problem for my code and I have contacted Microsoft to find out if it is causing problems for their PowerShell 5 OneGet "ARP Provider".

I have attached a reg export which I verified exhibits the problem when re-imported.

Darwin Sanoy.
Comment 1 djsnetbeans 2015-03-31 17:36:15 UTC
Opps, I mean we've seen it with 8.0.0 and 8.0.2 and Glassfish 4.1.

D.
Comment 2 phansson 2015-06-23 13:35:00 UTC
Yep, I can see this problem as well. I believe the problem (bug) has indeed always existed.

What happens is that someone (in this case NetBeans Installer) has put an 8-byte value into a Registry field that should only contain a 4-byte value. DWORDs are 4-byte.

If you use Registry Editor you can clearly see the problem if you look at something NBI has installed. You must look under either
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall (64-bit installers) or HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall (32-bit installers). For some reason I don't see the problem for those NBI applications installed with a 32-bit installer, meaning the stuff in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall. This can probably be explained when you read the next bit.

NBI actually sets a number of Registry key values but all of them are strings, with the exception of NoModify value. As far as I know this value already defaults to true (=1) if not present so the fact that Windows cannot interpret what NBI has put into the Registry does not have much effect .... until all other kinds of tools will start to explain as you've encountered.

So, what's the problem?  As far as I can see this is really just a very simple bug. In the NBI project (NetBeans Platform source) you have a file called jni_WindowsRegistry.c which defines various JNI methods that can then be used from within Java. One of these is called 'set32BitValue0(....)'.

It looks like this:

JNIEXPORT void JNICALL Java_org_netbeans_installer_utils_system_windows_WindowsRegistry_set32BitValue0(JNIEnv *jEnv, jobject jObject, jint jMode, jint jSection, jstring jKey, jstring jName, jint jValue) {
    unsigned short*  key       = getWideChars(jEnv, jKey);
    unsigned short*  name      = getWideChars(jEnv, jName);
    DWORD  dword     = (DWORD) jValue;
    LPBYTE byteValue = (LPBYTE) &dword;
    
    if (!setValue(getMode(jMode),getHKEY(jSection), key, name, REG_DWORD, byteValue, sizeof(name), 0)) {
        throwException(jEnv, "Cannot set value");
    }
    
    FREE(key);
    FREE(name);
}

One of the parameters passed to the setValue() function is the size (bytes) of the value. Unfortunately whoever made this has made a blunder by using 'sizeof(name)' for that parameter. It should have been the size of the value, not the size of the name, meaning sizeof(dword) or just a hard-coded value of 4.  Just imagine what sizeof(name) will give you if name happens to be 'NoModify'. Yep, that's right: It will be 8.

As I said, I believe this blunder has been in the code from the very beginning. It just hasn't had much effect until now.
Comment 3 phansson 2015-06-24 22:12:06 UTC
See https://bitbucket.org/phansson/nbi-native-jnilib-windows
for a fix to this problem. 

Honestly the sole reason why that project exists was that I had to have this problem fixed as our corporate customers were complaining about our software "messing up their Registry" and we could not wait for NetBeans team to fix the problem.
Comment 4 oldium 2017-03-03 21:28:13 UTC
Any update on this? I lost 1 hour finding why the Get-ItemProperty of Chocolatey failed and found this. Then I remembered that I had the same issue one year ago...

This issue is now 2 years old, the fix is a one-liner. Is there any plan to fix this or (I am just curious) is Netbeans project dead?
Comment 5 scott.fagg 2018-04-27 03:13:04 UTC
We encounter this too. Machines with Netbeans installed on our network often encounter issues when IT roll out software installs. Fix has been to remove and recreate the offending key.

If this has been known since 2015, is there any intention of fixing it ?
Comment 6 jszabo 2019-05-08 13:59:33 UTC
Netbeans also prevents powershell from listing the contents of uninstall registry keys:

get-itemproperty hklm:\software\microsoft\windows\currentversion\uninstall\*

...

get-itemproperty : Specified cast is not valid.
At line:1 char:1
+ get-itemproperty hklm:\software\microsoft\windows\currentversion\unin ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Get-ItemProperty], InvalidCastException
    + FullyQualifiedErrorId : System.InvalidCastException,Microsoft.PowerShell.Commands.GetItemPropertyCommand