- This topic has 10 replies, 4 voices, and was last updated 10 years, 9 months ago by
.
-
Posts
-
Just wanted to verify that the uninstallall switch actually does anything. When I use it the only thing it does is open the application, shouldn’t it immediately open the java uninstaller? Right now it does nothing different than if I just open the .exe on its own. I am using version 2.5. I am not using the /silent switch either since it says it wont work with it. Using the purge and clean switches works great, the only thing it doesnt do is actually remove the application from the program and features section of windows 7 which is causing an issue for its intended purpose. After the purge is the application still supposed to be listed or is that not working for me correctly as well? Any help would be great.
Thank you
The uninstallall switch will call each uninstaller in a row. Of course, this can only happen in JavaRa is actually able to detect an uninstaller. Can you confirm whether they’re detected when you open the executable normally?
The /purge switch will leave the ‘Add or Remove Programs’ entry in tact. It’s only supposed to remove the files and registry keys missed by the uninstaller.
Hi
Got the same problem here and I’m getting the following information in the JavaRa logs:
Exception encountered in module [JavaRa]
Message: Object reference not set to an instance of an object
at JavaRa.routines_registry.get_jre_uninstallers()
Trying to remove Java 7 Update 11 from a W7x86 client.
It works when I run it through the GUI but that wouldn’t be possible to use when uninstalling through a SCCM-deployment 🙁
As I wrote in my earlier post I’m running Windows 7 Enterprise x86 but I get the same result/error when running it on a Windows 7 Enterprise x64 client.
I’m having the same issue as raexx and vferg.
I would like to use JavaRA in an SCCM deployment to remove all discovered versions of Java from clients. JavaRa is an exceptionally effective tool during manual use, but I have no ability to deploy it to machines and run an uninstall silently. I get the same error as raexx described.
Is there currently any resolution/workaround/expected timeline for a fix?
Thanks for the great product. I hope this issue is resolved soon. JavaRa is going to be a lifesaver for us.
There’s still no ETA for a bug fix.
Just to give you a bit of background information; the issue is being caused by differences in Windows x86 and x64. Each stores the list of installed programs (and the MSI uninstall string) in a different location in the registry. The Windows registry is pretty cruel; automatically redirecting JavaRa’s registry access to the WOW6486Node (on x64) and throwing the “object reference not found” error when it realises the redirect was an idiot move.
The workaround is pretty simple. Setting the compiler flag to “x86” prevents the redirect from occurring, but makes the x64 registry hives invisible to JavaRa. Compiling against “Any CPU” has the inverse affect.
The logical answer would be to compile two different versions of JavaRa; but obviously this isn’t practical if being run across a network, as many different OS setups could be in use.
We’re currently investigating a workaround method that involves invoking native code, thus circumventing Windows’ annoying registry reparse “feature.”
Wouldn’t it be possible to add a check before running the Java-uninstall that checks if it’s running in a 32 or 64-bit environment?
After the check there could be 2 functions (x86 and x64) that executes depending on the environment detected.
raexx, I may be wrong, but if I understand the situation I don’t believe this would work.
Rather, could you provide an x86 compiled version of JavaRa for use on 32-bit windows to remove 32-bit Java, as well as on 64-bit windows to remove 32-bit Java (this being my use case, all 64-bit windows with 32-bit versions of Java installed), and provide a seperate, x64 compiled version, for use on 64-bit machines with 64-bit Java.
It would then be up to the end user to appreciate the intended application of each version and use it accordingly. If I ever happen to have 32 and 64-bit Java on a particular machine, I will simply deploy both versions of JavaRa.
From my perspective this isn’t even remotely an issue, as I, and others who deploy software day in and day out, are familiar with and frankly, accustomed to, deploying 32 and 64-bit versions of the same software.
Does this seem like a reasonable solution?
We could always take the Piriform approach and include JavaRa.exe and JavaRa64.exe in the downloaded archive.
Most people will automatically run JavaRa.exe, even if they’re on a x64 system; so the x32 binary would need to detect the OS and call the x64 binary when necessary. This call could be disabled if the user specifies a commandline argument, as it would be assumed such a user would be aware of the implications of calling the wrong binary.
Thoughts?
- You must be logged in to reply to this topic.