ICorPublish does not cross the 32/64 bit boundary

I mentioned earlier that ICorDebug does not cross the 32/64 boundary. If you want to debug a 32-bit managed app, you need to use a 32-bit version of the ICorDebug interfaces (or Mdbg). If you want to debug a 64-bit managed app, you need a 64-bit savy debugger. When you debug a 64-bit managed app in Visual Studio, VS will actually spin up the a 64-bit component to do the underlying debugging, and that remotes back to the 32-bit UI. 

Anyways, ICorPublish (and the CorPublish wrappers on top of them) have the same restriction. Although the underlying windows process enumeration APIs can view both 32 and 64-bit processes, the 64-bit version of ICorPublish only sees 64-bit managed processes.  A 64-bit ICorPublish will simply ignore 32-bit managed processes, and vice versa for 32-bit ICorPublish.


Disclaimer: I'm not saying this is a good design (although it does have some merits). However, a user ran into this and it caused some grief, and so I wanted to issue a public service announcement about it.


Brief Demo:

Here's a simple example using Mdbg. MDbg's processes enumeration ("pro") command is just a trivial wrapper on ICorPublish.


Let's say you have on the machine:
-  a 64-bit process, "la.vshost.exe", with pid=4028, AND
-  a 32-bit process, "excel.exe",  with pid=4720.

In 64-bit  Mdbg, you see:

mdbg> pro
Active processes on current machine:
(PID: 4028) C:\Temp\ListAppDomains\bin\Debug\la.vshost.exe
        (ID: 1) la.vshost.exe
mdbg> at 4720
Error: The operation failed because debuggee and debugger are on incompatible platforms. (Exception from HRESULT: 0x80131C30)

You can see that the 32-bit process (pid 4720) doesn't show in Publish/Mdbg, and if you try to be sneaky and attach to 4720 anyways, ICorDebug gives you a CORDBG_E_UNCOMPATIBLE_PLATFORMS (0x80131c30) error .


If you run it in 32-bit Mdbg, you no longer see the 64-bit process. But you do see the 32-bit process, and are able to attach to it.

mdbg> pro
Active processes on current machine:
(PID: 4720) C:\Program Files (x86)\Microsoft Office\Office12\excel.exe
        (ID: 2) TestAddIn.vsto|vstolocal
        (ID: 1) DefaultDomain

mdbg> at 4720
[p#:0, t#:0] mdbg> list mod
Loaded Modules:
:0      mscorlib.dll#0  (no symbols loaded)
:1      Microsoft.VisualStudio.Tools.Office.Runtime.v9.0.dll#0  (no symbols loaded)
:2      System.dll#0  (no symbols loaded)
:3      System.Core.dll#0  (no symbols loaded)
:4      System.AddIn.dll#0  (no symbols loaded)
:5      Microsoft.VisualStudio.Tools.Applications.Hosting.v9.0.dll#0  (no symbols loaded)

Comments (1)
  1. Michael Lyubomirskiy says:


    I figured you would be interested to know about  a neat application of your Blue compiler codebase. I used it to build a prototype of a[URL=http://www.michaelpundit.com/tech/LoggingDebugger.htm]logging debugger that displays variable values inside source code of the app[/URL], among other things. Kind of like Bil Lewis’s Omniscient debugging, but with a totally new, more powerful user interface, which eventually will display something like this:

    [color=green]//how debugger ought to work (embellished for clarity)[/color]

    String strY[color=blue]_uninit : "prev"[/color] = "prev";

    if(canDebugByLogging(str1[color=blue]_"so "[/color], str2[color=blue]_"easily"[/color])[color=blue]_true[/color])


    strY[color=blue]_"prev" : "100%"[/color] = ((bother[color=blue]_70[/color] + otherwise[color=blue]_30[/color])[color=blue]_100[/color] + "%")[color=blue]_"100%"[/color];


    Prototype is written in C# using Blue compiler codebase for parsing and type checking and works with a restricted subset of C# programs (for now can only have a single file 🙂 ). Nevertheless, I think my published results are already of some interest. The [URL=http://www.michaelpundit.com/tech/LoggingDebugger.htm]article on my work[/URL] is fairly detailed about the inner workings, problems that had to be solved, stuff that remains to be done. I think that the [URL=http://www.michaelpundit.com/tech/LoggingDebugger.htm#sql_search]searching the log of execution with SQL[/URL] is a particularly interesting concept. The code base is released under permissive license.


Comments are closed.

Skip to main content