Login or Sign Up

Support Forum

Registration is not required to ask a question. If you're a Pro Club member,
please use our Priority Support page for a faster response.

Ask a Question
All Questions
System Ninja
Bzzt! Image Editor
Before you ask a question

1. Make sure you're using the most recent version of the program.

2. Try searching the forum, perhaps your problem has already been described and solved.

3. Please provide following info:
– OS architecture (x86 or x64)
– Screenshot if applicable
– Step to reproduce issue

/uninstallall working?

Home Forums Product Support JavaRa Support /uninstallall working?

Viewing 10 posts - 1 through 10 (of 11 total)
  • Author
  • #9747 Reply

    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

    #9748 Reply
    Shane Gowland

    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.

    #9752 Reply


    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 🙁

    #9769 Reply
    Shane Gowland

    What operating system are you running? And is it x86 or x64?

    #9770 Reply

    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.

    #9772 Reply

    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.

    #9775 Reply
    Shane Gowland

    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.”

    #9777 Reply

    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.


    #9778 Reply

    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?

    #9779 Reply
    Shane Gowland

    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.


Viewing 10 posts - 1 through 10 (of 11 total)
Reply To: /uninstallall working?
Your information: