Case of crashing installer or unnecessary heap corruption by GROOVEEX

December 7, 2013

I was asked to solve an issue of a crashing installer. The symptoms provided were a bit vague: it only happened sometimes, only on specific machines, and it seems to have started after the company installed Office 2010. The installer executable is produced by NSIS scriptable install system, so there are no symbols for it, nor much ability to change or even see its code. So after finding a machine that was able to reproduce the bug i looked at this message:


So it seems there is an unhandled exception in the installer process. I have attached the debugger (WinDBG in this case) and re ran the installer again. When the debugger reached a second chance exception, i ran the “!analyze –v” command to get a bit more information on it, and this is the output:


So it seems that the heap was corrupted. I’ve used the “!heap –s –v” command to get a better view of the heaps in the process (-v is for verify, –s is for statistics), and this is the produced output:


So what we can see here is that the heap has performed some inner checks, when RtlFreeHeap was called and found out that the the heap block passed as a parameter has already been freed. Normally, this would not cause an exception but we can see that the flag “Termination on corruption” was enabled. What this also means is if this flag was disabled there is a chance that the installer would have ran to completion just fine! By using a search engine you can find this msdn page that explains about a way to enable and disable this flag:

HeapSetInformation function

And in order to find who is setting it to enabled, lets put a breakpoint at the mentioned function HeapSetInformation using the “bp kernel32!HeapSetInformation” command. bp sets the breakpoint and kernel32 specifies the name of the module  that contains this function (which you can also find on the same msdn page). I have started the installer again, set the breakpoint and made sure that the Termination on corruption flag is DISABLED at the start of the run:


Now, when we proceed with the installation, during the opening of FolderPicker dialog, in which i specified the installation directory, the breakpoint was hit:


Lets take a closer look at the top 6 frames. What we see at the top frame is the method on which the breakpoint was hit. Below there is a method called DllUnregisterServer in module GROOVEEX calling it. Notice that the method name is most certainly incorrect since the offset is way too big to be the code inside this method. But the module name is correct, and we can see that it is loaded by SHELL32, most certainly as a plug-in for the folder picker dialog.

From here there are two ways to proceed:

1. Search for grooveex.dll online, and you will find that it is a component used by Office for SharePoint integration which you can uninstall


2. Use Autoruns from Sysinternals and remove the registration of GROOVEEX.dll from shell (there are a few places in the registry, i have used the search feature to find them all)


Add comment
facebook linkedin twitter email

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>