Lovely. Having a bug reported to you in 2015, and acknowledged, that makes software crash and not fixing it.
For NetBeans (still one of the major IDEs) and related stuff like GlassFish, this is too true (a workaround is in the Solution steps) below: [WayBack] Bug 251538 – Your Installer is Creating Invalid Data for the NoModify DWORD Key which crashes enumeration of the Uninstall Key in at least PowerShell, and copied to [WayBack] [NETBEANS-2523] Netbeans 64-bit creates invalid nomodify value in windows registry for years – ASF JIRA.
This one appears for instance when running choco install --yes jre8 (but is certainly not limited to it) as it inspects uninstall registry values which have been corrupted and resulted into [WayBack] “Specified cast is not valid” on jre8 upgrade · Issue #18 · proudcanadianeh/ChocoPackages · GitHub.
Anyway: back to the NoModify issue:
I encountered it in 2019, when switching my JRE installations to become chocolatey based.
Solution steps
- Run the script mentioned in [WayBack] powershell – How to resolve “ERROR: Specified cast is not valid.” error during installation? – Super User:
Run the below:
Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* | % { write-host "Key Name:" $_.PSChildName }
This should return some results, then, will return the Specified cast error. The error will occur on the key harboring the invalid subkey.
- Then inspect the keys after that in regedit, and watch for any value of type
REG_DWORD with a value (invalid DWORD (32-bit) value) (usually named NoModify
- Note those keys, and find them in
appwiz.cpl
- Uninstall the accompanying software
On my systems
Delete the below pieces of crap.
Then run choco install --yes jre8 again.
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\nbi-glassfish-mod-3.1.43.0.0
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\nbi-nb-base-7.0.0.0.0
Luckily, the NetBeans uninstaller can uninstall GlassFish at the same time:
Do not re-install, as they re-insert the corrupt data.
–jeroen
Like this:
Like Loading...
The Wiert Corner - irregular stream of stuff 
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.