![]() Turning on the Lower Pane to view DLLs ( View > Lower Pane View > DLLs), I can see it is described as Microsoft Component, but the description is too generic to make out the purpose: You can see the stack growing with a couple dozen calls to some component named GKExcel.dll. Identifying the cause was a simple matter of turning to Process Explorer and examining the stack of the working program thread: The files were not ridiculously large, and opening the same files locally did not present a problem. In other cases, the file would not open at all, causing the Office application (Word, Excel) to become unresponsive and hung up. In some cases, the file would open, but only after a delay of a few minutes. One of the DLLs trying to get registered was getting blocked.Īfter a recent security update for our XP workstations, a couple complaints came in where user’s were having difficulty opening Microsoft Office files across the network. This has since been corrected by MacAfee with a HIPS update. After doing so, the MSI runs and the application installs as expected. ![]() I then reach out to our McAfee enterprise admin and ask him to disable HIPS on one of my workstation. ![]() To further confirm the problem is being caused by McAfee, I perform the install on a virtual machine where McAfee is not installed and it proceeds normally. I have no idea what removing this action might have elsewhere so this merely a hack. Without that row, the MSI install completes normally or so at least it seems. Through a quick process of elimination using Orca to remove some of the rows in the CustomAction table, I narrow down the cause specifically down to action ISSelfRegisterCosting. However, there is a bit more insight as the entry point is revealed and I can see the problem has something to do with the CustomAction table of the MSI itself. You can click the Thread ID like a hyperlink to follow it down in the report, expanding the thread. For the most part, the analysis summary can be ignored.Ī little bit down in the report points me to what I was seeing in Process Explorer with the problem thread that was using all the CPU time: It will do its best to figure out the issue in the most vague way and you almost always need to do some interpretation of your own. When it is installed, simply right-click the dump file and select Analyze Crash/hang Issue from the context menu and point it to the crash file. It has a very high learning curve and if you don’t use it much, its easy to forget everything except the old faithful !analyze –v or !analyze –v –hang. I have grown increasingly lazy and forgetful over the years with WinDbg. So, to confirm what I was seeing, I used the Task Manager to dump the msiexec process that was using the CPU time by right-clicking it and select Create dump file (which can also be done via Process Explorer):ĭumps can be analyzed with WinDbg or a tool like DebugDiag 2.0. Note, this might not be entirely abnormal as you can always expect any anti-virus suite to be hooking itself into any number of processes. You can see a 3rd party component here (HCApi – McAfee HIPS) at play. From here, I opened the thread by selecting it and clicking Stack: The thread that is doing all the work (or in this case getting hung up) is indicated by the Cycles tab. ![]() Opening the process details, I select the Threads tab. ![]() There were multiple processes running, but I could see one process, though, eating CPU resources, and this was likely where I might find the culprit: After manually deleting the components from the file system (it was missing from Programs and Features), I ran the MSI again and this time used Process Explorer to look inside the hung msiexec processes. However, the root issue still needed to be identified as I had no idea what else in the MSI was failing to complete. To confirm, I manually registered all the components in the program directly via the command line:įOR /R "C:\Program Files (x86)\ApplicationFolder" %G IN (*.dll) DO "%systemroot%\system32\regsvr32.exe" /s "%G").Īfterwards, the application with the dependency launched without error and Outlook was no longer crashing. My guess was that the application’s components were not getting registered. 93, time stamp: 0x52d811c0įaulting application start time: 0x01d12d4e055d29fcįaulting application path: C:\Program Files (x86)\Microsoft Office\Office14\OUTLOOK.EXEįaulting module path: C:\Program Files (x86)\Interwoven\WorkSite\iOutlook\imFileSite.dll 1000, time stamp: 0x514a1b69įaulting module name: imFileSite.dll, version.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |