Hello again. The help I received last time was excellent. I’m hoping someone will be able to help me again this time.
I’ve encountered a problem with two applications, TrueCrypt 6.3a and StarUML 5.0. After creating and deploying the packages, both return as successful installations.
The problem occurs when a user logs into the client machine and attempts to run the program. TrueCrypt prompts the user for an administrator username and password via UAC and StarUML crashes with an EOleSysError.
I’ve been able to resolve both issues with these programs by having an administrator log into the client machine and run each program. According to the documentation, each program must be run once by an administrator before it will work at a user level. The administrator does not get any errors. When the user logs back into the client machine, both programs launch and are fully functional.
I thought the problem could be fixed by running the program after installation through BigFix using ActionScript. Below are part of the fixlets for each program.
TrueCrypt 6.3a:
extract TrueCryptexe.tmp wait __Download\TrueCrypt.exe -ai run
"C:\Program Files\Security\TrueCrypt\TrueCrypt.exe"
StarUML 5.0:
extract staruml-50-with-cmexe.tmp wait __Download\staruml-5.0-with-cm.exe /VERYSILENT run
"C:\Program Files\StarUML\StarUML.exe"
Both fixlets have been tested with the Fixlet Debugger and both succeed in running the program after installation. However, when the user logs into the client machine after deploying these fixlets, both errors still occur.
Correct me if I’m wrong, but from my understanding when BigFix runs an application it will run it under the System context. I’m guessing that the System context is different than the Administrator context and therefore the applications are unable to do what they need to do in order to run correctly.
Does anyone have any suggestion as to what I could do? I feel as though there already exists a way to run applications as administrator after installation, but I’m just overlooking it.
Correct, system context is the machine’s account, not the local administrator account. You could use runascurrentuser.exe and filter the take action dialog to only be relevant if an administrator is logged on, but the ability to specify the user it will run as is more challenging. There are execution tools to do that (runas.exe is built into Windows, and many people like psexec.exe). However, all involve specifying and transferring an administrator password, which won’t fly in some environments.
@JackCoates After looking into RunAsCurrentUser.exe documentation and uses, I don’t think that it will help me in this context. And unfortunately specifying an administrator password is not an option for me in the environment I’m working in. However, thank you very much for your reply.
@boyd That’s a good point; I didn’t consider the device driver being an issue and the reason for needing admin rights. I will try this very shortly and let you know if it works.
As for StarUML, I found a resolution to the EOleSysError message in the StarUML support forums. The post,
linked to here
, states that a possible solution is to run it as administrator once. I’ve tried both other options mentioned in the post (reinstall and running in Windows XP Service Pack 3 compatibility) , but neither of them worked. Upon further investigation, I found that the solution to EOleSysErrors with other applications is to just run it as administrator once.
If it helps, here is the message that EventViewer throws when trying to run StarUML:
[Error] Faulting application name: StarUML.exe, version: 5.0.2.1570, time stamp: 0x2a425e19 Faulting module name: KERNELBASE.dll, version: 6.1.7600.16385, time stamp: 0x4a5bdaae Exception code: 0x0eedfade Fault offset: 0x00009617 Faulting process id: 0x144 Faulting application start time: 0x01cb1882d1ac893f Faulting application path: C:\Program Files\StarUML\StarUML.exe Faulting module path: C:\Windows\system32\KERNELBASE.dll Report Id: 10ce5e9f-8476-11df-a3a3-001e4fe17dcf [Information] Fault bucket 1382032764, type 1 Event Name: APPCRASH Response: Not available Cab Id: 0 Problem signature: P1: StarUML.exe P2: 5.0.2.1570 P3: 2a425e19 P4: KERNELBASE.dll P5: 6.1.7600.16385 P6: 4a5bdaae P7: 0eedfade P8: 00009617 P9: P10: Attached files: C:\Users\jpf5067\AppData\Local\Temp\WER905.tmp.WERInternalMetadata.xml These files may be available here: C:\Users\jpf5067\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_StarUML.exe_28d565c93cc8eb46d60868bc263151bab4d799_0f730b08 Analysis symbol: Rechecking
for solution: 0 Report Id: 10ce5e9f-8476-11df-a3a3-001e4fe17dcf Report Status: 0
I will try to take a look at StarUML when I get a chance. I have a feeling it’s trying to write registry keys or files on the first run, but can’t do so in the user context. This could be another job for ProcMon.exe
TrueCrypt is running completely fine now thanks to your fix. Also, I exported the TrueCrypt key from a test machine since our installer is an .msi and our key is a bit different and we used the Windows Registry Wizard to deploy it to the machines. But I’m happy to say that thanks to your help we shouldn’t have any more problems with TrueCrypt
As for StarUML, we redeployed with your fix and we’re still getting the same error (EOleSysError: Error accessing the OLE registry). I ran ProcMon.exe with a filter on ProcessName = StarUML.exe to capture the events up to the error. You may download it
here
. I will have to run another capture tomorrow of a fully successful first run from an administrator account.
How were you able to determine that StarUML.exe is an ActiveX executable? Through ProcMon? If there is any more information I can provide to you, just ask. Thanks so much for your help boyd, I really appreciate it!
With ProcMon running, I ran StarUML.exe as an administrator to see what it was doing. I then filtered by RegSetValue operation in ProcMon to see what what registry values were getting set. It was setting a lot of values in HKR\CLSID (or something like that) which hinted that it was trying to register itself.
You can also try registering the other DLLs that come with StarUML:
Once again you’ve come through for us! StarUML is working perfectly now that the modules are registered. I used a tool called RegDllView to compare the registered .dll files between a working version of StarUML and the one that was having the problem. Pgmr101.ocx, WinGraphviz.dll and OptMgr.dll were registered, however all of the modules weren’t. Now I understand why the problem was occurring against KernelBase.dll as it was trying to register those modules but can’t in a user context.
