Batch then MSI error

Spark Spark Support
1

So I used a custom batch file to push spark out to my clients from version 2.0 - 2.0.6. It worked great but occasionally it would glitch and skip an update.

I decided to try the MSI file after it had gone through a few revisions at 2.0.7

So I pushed the MSI out via GPO and everything installed fine (or so I think) but it won’'t start and it kicks out errors.

I’'m not sure if this is due to the fact the batch file was used first or if the MSI is bad. But if I uninstall and clear the directory and then reinstall via the MSI file it works fine.

thought I’'d pass this info along and see if any one knows anything… below is an example of the log file:

  1. An unexpected error has been detected by HotSpot Virtual Machine:

  1. EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d74e917, pid=2608, tid=3096

  1. Java VM: Java HotSpot™ Client VM (1.5.0_08-b03 mixed mode)

  2. Problematic frame:

  3. V

T H R E A D -

Current thread (0x00856278): JavaThread “main”

siginfo: ExceptionCode=0xc0000005, reading address 0x00000008

Registers:

EAX=0x00000000, EBX=0x00b7ea64, ECX=0x0000deab, EDX=0x00000000

ESP=0x00b7e9ec, EBP=0x00856338, ESI=0x00000000, EDI=0x00856278

EIP=0x6d74e917, EFLAGS=0x00010246

Top of Stack: (sp=0x00b7e9ec)

0x00b7e9ec: 00856278 072cbc80 00b7ea64 6d0b203c

0x00b7e9fc: 00856338 00b7ea64 00000000 00856278

0x00b7ea0c: 072cbc80 00b7ea5c 072cbc80 0b836068

0x00b7ea1c: 0b836068 6d0b2357 00856338 00b7ea64

0x00b7ea2c: 00856338 00b7ea64 0108832f 00856338

0x00b7ea3c: 00b7ea64 00b7ea40 072cbc80 00b7ea68

0x00b7ea4c: 072cd600 00000000 072cbc80 00b7ea6c

0x00b7ea5c: 00b7ea88 01082b3b 072cd590 010864f0

Instructions: (pc=0x6d74e917)

0x6d74e907: 6a 01 56 ff 36 50 50 57 e8 0e de 02 00 83 c4 18

0x6d74e917: 8b 46 08 8b 0e 8a 1c 08 8b 4f 2c e8 13 bd fa ff

Stack: [0x00a80000,0x00b80000), sp=0x00b7e9ec, free space=1018k

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)

V

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)

j sun.awt.WindowsFlags.initNativeFlags()Z+0

j sun.awt.WindowsFlags.()V+11

v ~StubRoutines::call_stub

P R O C E S S -

Java Threads: ( => current thread )

0x00d93b50 JavaThread “Low Memory Detector” daemon

0x00d92778 JavaThread “CompilerThread0” daemon

0x00d91b58 JavaThread “Signal Dispatcher” daemon

0x00d88c40 JavaThread “Finalizer” daemon

0x00d877d8 JavaThread “Reference Handler” daemon

=>0x00856278 JavaThread “main”

Other Threads:

0x00d48398 VMThread

0x00db66a8 WatcherThread

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

Heap

def new generation total 576K, used 245K [0x03080000, 0x03120000, 0x03560000)

eden space 512K, 35% used [0x03080000, 0x030ad708, 0x03100000)

from space 64K, 100% used [0x03110000, 0x03120000, 0x03120000)

to space 64K, 0% used [0x03100000, 0x03100000, 0x03110000)

tenured generation total 1408K, used 119K [0x03560000, 0x036c0000, 0x07080000)

the space 1408K, 8% used [0x03560000, 0x0357dff8, 0x0357e000, 0x036c0000)

compacting perm gen total 8192K, used 2363K [0x07080000, 0x07880000, 0x0b080000)

the space 8192K, 28% used [0x07080000, 0x072ceca0, 0x072cee00, 0x07880000)

No shared spaces configured.

Dynamic libraries:

0x00400000 - 0x00419000 C:\PROGRA~1\Spark\Spark.exe

0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll

0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll

0x77d40000 - 0x77dd0000 C:\WINDOWS\system32\USER32.dll

0x77f10000 - 0x77f56000 C:\WINDOWS\system32\GDI32.dll

0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll

0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll

0x7c9c0000 - 0x7d1d4000 C:\WINDOWS\system32\SHELL32.dll

0x77c10000 - 0x77c68000 C:\WINDOWS\system32\msvcrt.dll

0x77f60000 - 0x77fd6000 C:\WINDOWS\system32\SHLWAPI.dll

0x774e0000 - 0x7761c000 C:\WINDOWS\system32\ole32.dll

0x77120000 - 0x771ac000 C:\WINDOWS\system32\OLEAUT32.dll

0x773d0000 - 0x774d2000 C:\WINDOWS\WinSxS\X86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6 .0.2600.2180_x-ww_a84f1ff9\COMCTL32.dll

0x5ad70000 - 0x5ada8000 C:\WINDOWS\system32\uxtheme.dll

0x6d6c0000 - 0x6d85b000 C:\Program Files\Spark\jre\bin\client\jvm.dll

0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll

0x6d280000 - 0x6d288000 C:\Program Files\Spark\jre\bin\hpi.dll

0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL

0x6d690000 - 0x6d69c000 C:\Program Files\Spark\jre\bin\verify.dll

0x6d300000 - 0x6d31d000 C:\Program Files\Spark\jre\bin\java.dll

0x6d6b0000 - 0x6d6bf000 C:\Program Files\Spark\jre\bin\zip.dll

0x6d000000 - 0x6d169000 C:\Program Files\Spark\jre\bin\awt.dll

0x73000000 - 0x73026000 C:\WINDOWS\system32\WINSPOOL.DRV

0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.dll

VM Arguments:

jvm_args: -Dappdir=C:\Program Files\Spark\

java_command:

Launcher Type: generic

Environment Variables:

CLASSPATH=.;C:\Program Files\Java\jre1.5.0_06\lib\ext\QTJava.zip

PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\ATI Technologies\ATI Control Panel;C:\Program Files\Diskeeper Corporation\Diskeeper;C:\Program Files\QuickTime\QTSystem;C:\Program Files\Common Files\Microsoft Shared\Integration Manager\

USERNAME=********

OS=Windows_NT

PROCESSOR_IDENTIFIER=x86 Family 15 Model 75 Stepping 2, AuthenticAMD

S Y S T E M -

OS: Windows XP Build 2600 Service Pack 2

CPU:total 2 (cores per cpu 2, threads per core 1) family 15 model 75 stepping 2, cmov, cx8, fxsr, mmx, sse, sse2, sse3, mmxext, 3dnowext, 3dnow

Memory: 4k page, physical 915720k(606828k free), swap 2219560k(1994940k free)

vm_info: Java HotSpot™ Client VM (1.5.0_08-b03) for windows-x86, built on Jul 26 2006 01:10:50 by “java_re” with MS VC++ 6.0

2

FYI… this is not the cleanest solution, but!

I deleted the directory %PROGRAM FILES%\Spark

then redeployed the application and all was well. So anyone who is having this trouble and needs a quick fix this will work

3

That’‘s great news, although I’'m wondering if for one reason or another the JRE was corrupted. Did you use the MSI installer with JRE?

Thanks,

Derek

4

I’'ll add some more info for your troubleshooting…

BATCH INSTALL

I installed the full version of every version of spark from 2.0.1 - 2.0.6 via the batch script in a startup script.

When 2.0.7 came out I ran it on my machine after uninstalling the older version for a week or so. (MSI full)

I then pushed it out to a client who didn’'t have spark yet via GPO… it install and worked fine.

2 days later I pushed 2.0.7 full out via GPO to all my staff. Within the next few days as people rebooted and got the update I saw my member list shrink and shrink… so I went to work trying to figure out why.

I found the log files (like the one above) in the Spark directory.

I reinstalled via the MSI file over the directory with no luck (and btw… spark doesn’'t even attempt to load when that happens… it just creates the log file)

So I decided to uninstall the files and reinstall. In the add/remove programs list there was the current batch install version as well as the new MSI 2.0.7 version.

I first tried to uninstall the batch version but it wouldn’'t do anything, but if I uninstalled 2.0.7 first then I could uninstall the batch version after and then reinstall 2.0.7 via the MSI file and it works.

The whole point of the batch file and GPO was to not have to go to every machine to install the software… now I was stuck with going to every machine to UNINSTALL it and REINSTALL it! so I tried a few methods and deleting the directory and then repushing out via GPO did the trick. I’‘m guess ing I have a few orphan registry files (left over from the batch install) but I’'m hoping the MSI isntalled overwrote a few atleast.

Let me know if you have any more questions.

5

I will bump the thread - I too have run into the same situation as well. I deployed using spark_2_0_7.msi 31.70 MB as some of my workstations had various levels (if at all) of java on them. At that point spark stopped working on those who have had various versions (2.0.3/4/5/6/even 7) of spark that was installed via the .exe. My only recourse has been uninstalling spark completely, wiping the c:\program files\spark directory & doing an install of the .msi once more. I have delt with mass deployments of upgrades from .exe installs to .msi installs in the past before (but none client side java apps) and have not run into this issue. Can this be fixed for the next minor release of spark?

Thanks,

a network admin without a lot of time on his hands

6

Same problem with 2.0.8 msi package.

I tried pushing out Spark vi GPO with the msi installer package (the one containing the JRE). Same problem. If Spark already exists on a machine, it will not run after the policy takes effect and pushes out Spark. It works just fine if there is no previous install of Spark on a machine.

Pretty much renders the msi package moot. As I will have to go to each machine and uninstall the previous installs first. Once I get the msi on all computers, then I can have the GPO uninstall the old one whenever I upgrade - or use Spark manager from that point on.

7

Like I said though… the work around is to create a batch file to delete that folder then redeploy the MSI package.

Works, and you never have to leave your seat

8

Will the developers be working on a msi package that will overwrite/delete previous installs, or do you see the status quo for the foreseeable future? Just curious.

9

So on new installs, you wish the msi to remove the old folder prior to installation?

Thanks,

Derek

10

Well I’'m not sure exactly what the problem is… but deleting the folder prior to pushing the MSI fixed it for me.

I’'m sure a better long term solution would be to find what the actual problem is.

But for now… it is a quick easy fix that would probably help out just about everyone in this boat.

So yes, I think I would implement that. ( I would however put a disclaimer on the download link incase anyone has any files they store there for any reason… I can’'t imagine why they would, but you never know)

11

I can’‘t think of any problems that this may cause, so I’'d vote yes.

I assume that a new install would have nothing to remove - so yes - take away something that isn’'t there. But an upgrade would not work unless that folder is removed - so again, yes - why would I want it there if it is going to break the upgrade?

This would be the same behavior as the regular exe installers, no?

I’'d like to hear suggestions on what problems this may cause for some people.