Ranjan Banerji

I have built several toolbars for IE and every now and then I end up modifying them and then end up having to debug them.  Up until now this was an easy process.  I would open the source code for the the toolbar DLL in Visual Studio (2005 or 2008) and on the debug property page I would set it to launch IE.  Any breakpoint in my code would get triggered.

Recently I upgraded to IE8.  At the same time I found a bug in one of my toolbars.  SO I set out to debug it and the moment I hit F5 I got the following error: “Error while trying to run project: Unable to start debugging.”.  So I started looking into what went wrong.  If I switched the debug setting from running IE to opening a URL in a browser then IE would launch but my toolbar DLL breakpoints were still not be called.  Was this a new IE8 security feature?  I didn’t think so as I could still debug websites by asking it to open a URL in the browser.

So then I attempted the next best way to debug.  Simply attach to the iexplore process via Visual Studio.  Uh oh! there were several iexplore processes running even though I had just one IE open.  Now I remembered reading about IE8 and how it launches each tab in its own process.  So which one do I attach to?  I went ahead and attached to all.  Still unable to debug.  This was no good.  So I started reading up on IE8 and stumbled upon this blog post:  http://blog.httpwatch.com/2009/04/07/seven-things-you-should-known-about-ie-8/ 

In the blog post under item #4 it talks about the fact that the IE8 process model is configurable.  You can what the maximum number of processes is for IE.  This is done by the following registry entry TabProcGrowth (DWORD) that is at:  HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main

If it does not exist then IE does whatever it wants to.  If set to 0 then IE will use just one process.  Now the debugger works.  I do not know if there is a better option, because with this option, post debugging its a good idea to go to the registry and remove TabProcGrowth so that IE8 can function as it was designed to.

This is a post so that I remember this problem and can fix it when it resurfaces 6 months later.  Though I really hope that in 6 months I will only be dealing with SQL Server 2008 and not 2005.  I recently setup two SQL Server 2005 environments and on one of them I just cannot connect to the Integration Service.  I also noticed that I was unable to create a backup maintenance plan.  A little research led to the following Microsoft Knowledge base article:

http://support.microsoft.com/kb/919224

In my case, I do not know if this is true for everyone, there were some discrepancies between how my machine was setup and the fix for the problem.

• Microsoft suggests registering the 32 bit dts.dll using %windir%\syswow64\regsvr32 "%ProgramFiles(x86)%\Microsoft SQL Server\90\dts\binn\dts.dll".  The problem I found is that dts.dll on my server was not in %ProgramFiles(x86)%\Microsoft SQL Server but instead it was in %ProgramFiles%\Microsoft SQL Server(x86)\90\dts\binn
• Registering the 32 bit dts.dll did not solve the problem.  I could connect to Integration Service but I was getting all sorts of strange errors.  So I went ahead and registered all the dts/binn DLLs.  Now everything works.

I do not know if by registering all the DLLs if I have created new problems.  But so far everything seems to be working fine.  If I do find problems I will update this post.