Windows Explored

Everyday Windows Desktop Support, Advanced Troubleshooting & Other OS Tidbits

Posts Tagged ‘Debugging’

The Case of the Failed MSI

Posted by William Diaz on December 3, 2015


I recently began encountering a problem where one of our application packages was getting hung during the install process. I could see the program directory correctly populated with application files but it seemed to get hung at end, and msiexec processes continued to run indefinitely. After manually killing each process, I checked to see if the application actually completed installing. When trying to run one of the applications that has a dependency on one of the failed MSI’s APIs, I encountered the following:

image

Further, Outlook was crashing when trying to load the application’s main component.

Faulting application name: OUTLOOK.EXE, version: 14.0.7012.1000, time stamp: 0x514a1b69
Faulting module name: imFileSite.dll, version: 8.5.3006.93, time stamp: 0x52d811c0
Exception code: 0xc0000005
Fault offset: 0x0008637e
Faulting process id: 0xd18
Faulting application start time: 0x01d12d4e055d29fc
Faulting application path: C:\Program Files (x86)\Microsoft Office\Office14\OUTLOOK.EXE
Faulting module path: C:\Program Files (x86)\Interwoven\WorkSite\iOutlook\imFileSite.dll

 

My guess was that the application’s components were not getting registered. To confirm, I manually registered all the components in the program directly via the command line:

FOR /R "C:\Program Files (x86)\ApplicationFolder" %G IN (*.dll) DO "%systemroot%\system32\regsvr32.exe" /s "%G").

Afterwards, the application with the dependency launched without error and Outlook was no longer crashing. However, the root issue still needed to be identified as I had no idea what else in the MSI was failing to complete. 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. 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:

image

Opening the process details, I select the Threads tab. The thread that is doing all the work (or in this case getting hung up) is indicated by the Cycles tab. From here, I opened the thread by selecting it and clicking Stack:

image

Stacks are read from the bottom up. You can see a 3rd party component here (HCApi – McAfee HIPS) at play. 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. 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):

image

Dumps can be analyzed with WinDbg or a tool like DebugDiag 2.0. I have grown increasingly lazy and forgetful over the years with WinDbg. 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 used DebugDiag instead. 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.

image

image

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. For the most part, the analysis summary can be ignored.

image

A 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:

image

You can click the Thread ID like a hyperlink to follow it down in the report, expanding the thread. It reveals a familiar site. 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.

image

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.

image

Without that row, the MSI install completes normally; or so at least it seems. I have no idea what removing this action might have elsewhere so this merely a hack. 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 then reach out to our McAfee enterprise admin and ask him to disable HIPS on one of my workstation. After doing so, the MSI runs and the application installs as expected. He inherits the problem.


Update

This has since been corrected by MacAfee with a HIPS update. One of the DLLs trying to get registered was getting blocked.

Advertisements

Posted in Troubleshooting, Troubleshooting Tools | Tagged: , | 9 Comments »

The Case of My Broken App in Windows 8

Posted by William Diaz on August 1, 2014


This is a case where the Application Event logs came in handy when my application started to crash upon loading on our Windows 8.1 images. Since my app was compiled as .NET, the stack in the error details pointed me to problem object:

image

When TextBlock3 loaded it was doing Environment.GetEnvironmentVariable(“SomeVariable”). The variable in question did not exist on our Windows 8.1 images. Although this did not seem to pose an issue for my Windows 7 dev box (it just would not display the TextBlock), Windows 8 will throw an exception if the variable does not exist and the app will crash. The likely cause my dev PC did not encounter this exception when running was because .NET framework 4.5 was not installed whereas .NET 4.5 is the default framework in Windows 8.

Posted in Troubleshooting | Tagged: | Leave a Comment »

An Oldie But Still A Goodie–Dr. Watson

Posted by William Diaz on October 3, 2011


A few years ago I started to see several complaints of Internet Explorer crashing in the course of a couple months. The error was one of the rather vague exception messages thrown at the time of the crash and didn’t allude to anything obvious. Tired of not being able to explain through any of the conventional troubleshooting methods, I did a little research into advanced troubleshooting techniques and came across the Windows XP default debugger, Dr. Watson. Sure it sounds a little cheesy but this is actually a helpful little gem that has assisted me in resolving many cases of unexplained application crashes. And even though Microsoft has done away with drwtsn32.exe in all Windows operating systems after XP, the majority of small and large enterprises are still using XP, which means it should be one of core tools of any Windows XP troubleshooting guru. You’ll also see how, despite Microsoft moving to WER, Dr. Watson can still be leveraged by the Windows Vista/7 OS (just for the hell of it).

To use Dr. Watson, you don’t need to do anything. By default, it is the default Windows XP debugger. When an application experiences a exception of sorts that leads to a crash, ideally it is designed to dump that process and create two files, a plain text drwtsn32.log and a dump file named user.dmp, the latter which requires WinDbg to open and analyze. If you are not sure if Dr. Watson is the default debugger, you can run drwtsn32.exe –i to make it the default. You can also confirm by going to HKLM\Software\Microsoft\Windows NT\CurrentVersion\AeDebug and looking in the Debugger string for drwtsn32 -p %ld -e %ld –g:
Read the rest of this entry »

Posted in Troubleshooting, Troubleshooting Tools, Uncategorized | Tagged: , , | Leave a Comment »