8

Here's the setup: I have an older piece of remote monitoring equipment, known as a Badger. The GUI control software that runs on Windows is a Java app, the CD has a date of 2003 but I think the software is much older. The setup.exe does not run on my AMD64 Windows 7 installation, I receive a 32 bit/ 64 Bit error, I suspect it might be a 16 Bit app (it's surely ugly enough).

Anyway, I tried to solve this with an XP VM Guest in VirtualBox on the AMD64 Windows 7 host. The setup.exe runs fine but when I try to launch the Java application I get an immediate Windows error:

java.exe has encountered a problem and needs to close.

If I click here to see what data this error report contains, I get:

AppName: java.exe AppVer: 0.0.0.0
ModName: javai.dll ModVer: 0.0.0.0
Offset: 0009b4e

When I view technical information about the error report, there is the usual binhex gibberish but some of the text complains about being out of memory, bad superclass, bad index, class storage allocation error, among others.

Behind the error is the CMD window with:

Symantec Java! JustInTime Compiler Version 3.00.029(i) for JDK 1.1.x, Copyright 1996-98 Symantec Corporation

Later, at home on my iMac which also had an XP VM Guest in VirtualBox available, I installed the software and successfully launched it. I then exported the VM, imported it into my Windows 7 AMD64 host and ran right into the same error as described above.

Obviously, the Hosts are very different from each other but I'm wondering what specifically is the cause for this behavior, where it works on the Mac host but not on the AMD/Windows host?

slhck
  • 235,242
baraboom
  • 834

4 Answers4

1

Some CPU differences are visible to guests in virtual machines like VMware, Virtual PC (current version) and VirtualBox which use native code execution.

Try:

  • disabling hardware virtualization. Machine -> Settings -> System -> Acceletation; uncheck Enable VT-x/AMD-V
  • using a different virtual machine program, maybe an actual emulator such as Bochs or QEMU (the latter would have to be appropriately configured as it can use native execution as well as emulation).
  • running it on a different PC
Hugh Allen
  • 10,120
1

I actually worked on the software that you're referring. Things we've done in the past to get around strange java/OS issues was to change the GUI shortcut target to use your installed Java version rather than the Java version we sandboxed on the CD. Try changing that and then running the shortcut to see if that helps.

Good Luck!

Ryan
  • 11
0

I can't answer your specific question about what is different between the hosts but you might be able to get your Badger GUI control software to work by using a more modern Java Virtual Machine.

Try installing the latest JVM in your Windows 7 AMD64 host - Windows XP guest VM, and using that to run the program.

Download here: http://www.java.com/en/download/manual.jsp

Shane Wealti
  • 317
0

I wonder if the problem you are having is related to the Windows 7 firewall blocking the software from connecting to the Badger equipment and the Java application rather than handling that exception gracefully just ends. I am not familiar with the Badger equipment but that fact that you got the VM working on the iMac (which by default does not enable the firewall) but the same VM failed on the Windows 7 box (which by default does enable the firewall) leads me to believe that may be the problem. I would suggest using the Service Manager application on Windows 7 to temporarily stop the firewall service, and run your test again to see if it is successful this time. If it is then you will have to check the Badger documentation to see what ports it uses and allow those through your firewall. If it is using the SNMP protocol then you would need UDP/161 and UPD/162 open.