none
COM Interop behaving inconsistently on 32 bit and 64 bit Windows RRS feed

  • Question

  • Hello,

    I have a 32 bit application that I'm moving to Windows 7 (x64)/Windows 2008 R2 that depends on a 3d party, 32-bit ATL dll.  The 3d party is no longer around so getting an updated DLL isn't likely.  After searching through various developer forums, I worked through the normal 32-bit WOW64 issues (compiling the app with a target of x86, registering the 3d party DLL, etc.).  The application works flawlessly on 32-bit Windows 7 and, interestingly enough, on Windows 2003 R2-x64, but does not on Windows 7-x64 and Windows 2008 R2.  No errors are logged.

    The 3d party DLL has a subscription mechansim that calls a public method in my .NET application when certain conditions are met.  The callback method name is provided to the DLL as a string, so I'm assuming the DLL uses the COM equivalent of reflection (I'm not versed in COM/ATL programming) to find the callback method and invoke it.  My application is .NET (tried 2.0 through 4.0) and calls references the 3d party DLL via COM Interop.  As I said before, the application works fine on 32-bit versions of Windows and Windows 2003 R2-x64, but the callbacks are never executed on 64-bit versions of Windows 7 and 2008 R2. 

    Here's the interesting part.  When I use the 3d party dll in a script embedded in a web page (i.e. no interop), everything works great on all operating systems.  The only thing I can think of (here's my brilliant flash of the obvious) is that there is something weird going on with COM Interop on Win7/2008R2 x64 versions.  The .NET assembly I'm running is tagged as COM visible and so is the particular callback method. 

    Is there anything I can do to correct this, or is this a bug?

     

    Regards,

    -John

    Sunday, November 28, 2010 8:52 PM

Answers

  • i'm fairly certain this is not a bug but related to windows security.

    Try running elevated an see if that changes anything.
    Or try running using the credentials used for the app pool of your IIS

    • Marked as answer by eryang Monday, December 27, 2010 1:42 PM
    Monday, November 29, 2010 4:09 PM
  •   Is this ATL dll loaded within the process of the .net client OR is the ATL dll hosted out of proc or in a COM+ process (dllhost.exe)

     

       Hi, It would be good to know how does it hook up to method in .net client from this ATL component. There is ATLAdvise (http://msdn.microsoft.com/en-us/library/26k10xyy(v=VS.90).aspx) and AtlUnAdvise (http://msdn.microsoft.com/en-us/library/7s2bbwhc(v=VS.90).aspx) but none of them are take function name literally. So it would be good to know exactly how this hooking mechanism works..

     

    Also does yours .NET class (for whose callback function is registered) exposes to ROT via pinvoke etc?

     

      You can try procmon (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) and see for any access denied that occurs while running this application and try and compare these logs in win2003 (x64 bit) and win7\win2008 R2(x64 bit)

     

      the last resort would be to capture all firstchance exceptions for the application and analyze those. 

     

    My suggestion is to see about what options to check out. Here is some info for more in depth

    level into the problems through support.

    There are various support options such as advisory and per issue. Please visit the below link to see

    the various paid

    support options that are available to better meet your needs.

    http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone

     

     


    bill boyce
    • Marked as answer by eryang Monday, December 27, 2010 1:41 PM
    Monday, December 6, 2010 7:34 PM
    Moderator

All replies

  • i'm fairly certain this is not a bug but related to windows security.

    Try running elevated an see if that changes anything.
    Or try running using the credentials used for the app pool of your IIS

    • Marked as answer by eryang Monday, December 27, 2010 1:42 PM
    Monday, November 29, 2010 4:09 PM
  • Thanks for the response. I should have been more clear in my original post. I am running elevated. My app is a console application not running under IIS. Regards, -John
    Monday, November 29, 2010 4:58 PM
  • I'm still struggling with this.  Perhaps someone from the Microsoft team can shed some light.  Here's the latest I've tried to determine the difference between 32 bit and 64 bit windows (at least Win 7 and Windows 2008 R2).

    Running Spy++ I've discovered that on 32 bit Windows 7 there's a hidden window that looks like it handles the 3d party dll's async notifications.  Messages appear to be processed by that window when the 3d party dll detects that certain conditions are met (this is the behavior I am expecting).  When I switch to Windows 2008 R2, that hidden window does not exist in Spy++, so I'm thinking that's where the problem is. 

    Clearly, there's something not quite the same in WOW64 with respect to COM/ATL.  Any ideas would be appreciated.

     

    Regards,

     

    -John

    Sunday, December 5, 2010 6:43 PM
  •   Is this ATL dll loaded within the process of the .net client OR is the ATL dll hosted out of proc or in a COM+ process (dllhost.exe)

     

       Hi, It would be good to know how does it hook up to method in .net client from this ATL component. There is ATLAdvise (http://msdn.microsoft.com/en-us/library/26k10xyy(v=VS.90).aspx) and AtlUnAdvise (http://msdn.microsoft.com/en-us/library/7s2bbwhc(v=VS.90).aspx) but none of them are take function name literally. So it would be good to know exactly how this hooking mechanism works..

     

    Also does yours .NET class (for whose callback function is registered) exposes to ROT via pinvoke etc?

     

      You can try procmon (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) and see for any access denied that occurs while running this application and try and compare these logs in win2003 (x64 bit) and win7\win2008 R2(x64 bit)

     

      the last resort would be to capture all firstchance exceptions for the application and analyze those. 

     

    My suggestion is to see about what options to check out. Here is some info for more in depth

    level into the problems through support.

    There are various support options such as advisory and per issue. Please visit the below link to see

    the various paid

    support options that are available to better meet your needs.

    http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone

     

     


    bill boyce
    • Marked as answer by eryang Monday, December 27, 2010 1:41 PM
    Monday, December 6, 2010 7:34 PM
    Moderator
  • Thanks!  Procmon is a great suggestion, I'll set that up and run a few tests. 

    The subscription mechanism is a method exposed by the DLL that accepts the callback procedure name (as a string), and the object containting the procedure as IDispatch.   While I don't have the DLL's source code, I suspect it uses the IDispatch::Invoke method to trigger the callback procedure.  Has IDispatch support changed in Win 7/2008 x64?  I don't see anything in the blogs or on MSDN.

    The DLL is added as a reference in Visual Studio (2010) and the appropriate interop assembly is generated.  Since it works on 32 bit windows and 2003 R2 x64, I assume that the public classes/methods in my application are exposed properly to the DLL via the interop assembly.  Whether it uses R.O.T or not I can't say.

     

    I'll run the procmon and report what I find.

     

    Thanks,

     

    -John

     

     

     

    Tuesday, December 7, 2010 2:38 PM