How to debug ActiveX controls under IE8
I have an inproc ActiveX control. I have recently put IE8 on my development machine, and can not longer debug the control. Prior to IE8, the control was loaded into the address space of IE and to debug, I would start IE under the debugger, then when my control was loaded, the breakpoints would be activated.
Apparently with IE8, the control is no longer loaded into IE8's address space, but rather into a separate process. I have tried attaching the other process with the debugger, but I am unable to get any breakpoints to work, nor am I able to break the process.
Does anyone know how to debug ActiveX controls under IE8?
Apparently with IE8, the control is no longer loaded into IE8's address space, but rather into a separate process. I have tried attaching the other process with the debugger, but I am unable to get any breakpoints to work, nor am I able to break the process.
Does anyone know how to debug ActiveX controls under IE8?
JohnGaby--I meant to add this
http://www.microsoft.com/windows/internet-explorer/readiness/developers.aspx
http://www.microsoft.com/windows/internet-explorer/readiness/developers.aspx
ASKER
Thanks for the input. I have already read through much of that material, and did not find anything that addressed using a debugger with my ActiveX control (I am using Visual Studio 2008). Can you point me to a specific place where these issues are addressed?
Thanks.
Thanks.
JohnGaby--Since I do not know what your ActiveX control is, I can only offer general suggestions.
http://download.microsoftvirtuallabs.com/download/8/a/7/8a71365b-4c80-4e60-8185-8f12f59bf1d4/DebuggingandApplicationCompatibility.pdf
http://my.opera.com/sirnh1/blog/2008/03/06/internet-explorer-8-new-functions
http://download.microsoftvirtuallabs.com/download/8/a/7/8a71365b-4c80-4e60-8185-8f12f59bf1d4/DebuggingandApplicationCompatibility.pdf
http://my.opera.com/sirnh1/blog/2008/03/06/internet-explorer-8-new-functions
ASKER
Thanks again for the links. The ActiveX control is an ATL com control written in C++. Visual Studio 2008 is used as the debugger. The problem I am having is that the control (which runs as an 'inproc' com object) no longer runs within the address space of IE8, but rather a separate process. Unfortunately, I do not seem to be able to attach that process to my debugger in a manner that allows me to set breakpoints, or break execution.
The only articles I can find regarding debugging with IE8 concerns the built in debugging tools for CSS, HTML, and JavaScript. These are not helpful to me in debugging my C++ binary dll.
The only articles I can find regarding debugging with IE8 concerns the built in debugging tools for CSS, HTML, and JavaScript. These are not helpful to me in debugging my C++ binary dll.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
The author did not comment on the solution, because there was NO solution. I am still waiting for someone to tell me how I can debug my activeX control under IE8.
I too am struggline with this.
I managed to figure out a way to do it tonight. Here's the process I used.
1) Start IE on its own.
2) load my page which instantiates my ActiveX.
3) Use the MS SysInternals Process Explorer to find the process which loaded my ActiveX
4) Instruct the VS Debugger to "attach" to that process. Take care to switch the debugger manually to attach in 'native' mode. It seems to want to attach in 'script' mode now.
5) your break points should get hit.
MS has created a nightmare for developers faithful to their platform and who actually develop software for IE using the ActiveX model. This is going to have a major impact on development progress. Gone are the days where you just hit F5 and your break point triggers.
Good luck.
I managed to figure out a way to do it tonight. Here's the process I used.
1) Start IE on its own.
2) load my page which instantiates my ActiveX.
3) Use the MS SysInternals Process Explorer to find the process which loaded my ActiveX
4) Instruct the VS Debugger to "attach" to that process. Take care to switch the debugger manually to attach in 'native' mode. It seems to want to attach in 'script' mode now.
5) your break points should get hit.
MS has created a nightmare for developers faithful to their platform and who actually develop software for IE using the ActiveX model. This is going to have a major impact on development progress. Gone are the days where you just hit F5 and your break point triggers.
Good luck.
ASKER
Thanks for the response. Have you actually done this? I tried it, and although I was able to attach the process, I was not able to set breakpoints or even break execution. Perhaps I was not attaching the correct process? How did you determine what process actually loaded the ActiveX control? What I did was to have my control throw up a message box, and then look for the process that owned that window. Attaching the debugger to that process did not work for me, however.
By the way, this is no longer an issue for me in this particular case, since I switched to using an .exe version of the control (for reasons other than debugging), and am able to attach and debug my own process without a problem. I am still interested in finding a solution for future projects, however.
By the way, this is no longer an issue for me in this particular case, since I switched to using an .exe version of the control (for reasons other than debugging), and am able to attach and debug my own process without a problem. I am still interested in finding a solution for future projects, however.
Yes, I have done this. I used the MS SysInternals Process Monitor (step #3 above) to determine which process loaded my ActiveX. I then attached the debugger to it, overriding the default 'script' mode so that I could do 'native' debugging and it works. It's just realyl painful.
Have you seen the tech notes about IE8 and the Losely-Coupled IE architecture that explains all this?
read about it here:
http://blogs.msdn.com/ie/archive/2008/03/11/ie8-and-loosely-coupled-ie-lcie.aspx
http://blogs.msdn.com/askie/archive/2009/03/09/opening-a-new-tab-may-launch-a-new-process-with-internet-explorer-8-0.aspx
I've had really strange results actually using this. When I set the TabProcGrowth=0 and I then start IE fro the debugger I get an IE error that there is connectivity issues; the browser can't see the network. When I use TabProcGrowth=1 the browser works but my tab/activeX is in a different process and I have to use the process stated above to debug. Long gone are the <press F5 & hit a breakpoint> days.
Have you seen the tech notes about IE8 and the Losely-Coupled IE architecture that explains all this?
read about it here:
http://blogs.msdn.com/ie/archive/2008/03/11/ie8-and-loosely-coupled-ie-lcie.aspx
http://blogs.msdn.com/askie/archive/2009/03/09/opening-a-new-tab-may-launch-a-new-process-with-internet-explorer-8-0.aspx
I've had really strange results actually using this. When I set the TabProcGrowth=0 and I then start IE fro the debugger I get an IE error that there is connectivity issues; the browser can't see the network. When I use TabProcGrowth=1 the browser works but my tab/activeX is in a different process and I have to use the process stated above to debug. Long gone are the <press F5 & hit a breakpoint> days.
http://msdn.microsoft.com/en-us/library/cc288472.aspx