FUSLOGVW.exe - doesn't work when used with COM?

I've been debugging an issue where my application has thrown an exception with HRESULT 0x80131040 when doing ::CoCreateInstance on a clsid associated with a C# component designed to be used from within a COM Framework.

Searching found the following:
http://blogs.msdn.com/suzcook/archive/2003/05/29/57120.aspx
http://www.dnjonline.com/article.aspx ID=jul02_tech (needs registration)

So, to debug my problem, I inserted the registry keys in
HKEY_LOCAL_MACHINE\Software\Microsoft\Fusion
LogResourceBinds with a DWORD value of 1
and
ForceLog with a DWORD value of 1
(LogFailures has a value of 1)

Now, running FUSLOGVW and selecting "Log Failures" - I'd expect to see the failure that caused 0x80131040
But the only event I can see is the original application (unmanaged .exe - the COM application that makes use of the C# component) binding to mscorlib.

There are a number of C# components that are consumed from COM from this application, and one of them fails, but there is no log of any of them displayed.

Does this tool not work when COM is creating the components

(Note: I actually fixed the bug, this was because the C# component originally didn't have a Guid attribute - a new Guid was created every time it was built leading to loads of cruft in the registry. Clearing the registry of all previous entries cured the problem, but I'm still curious about how to otherwise debug 0x80131040 and whether the FUSLOGVW tool should have worked).

Thanks,
Gary

Answer this question

FUSLOGVW.exe - doesn't work when used with COM?

mohammad272005

Hi Gary,

In general, if the class you were trying to CoCreate didn't have a GuidAttribute then you weren't getting far enough along the COM activation path for fuslogvw to come into play. Since there was no guid, there was no registry entry telling COM where to find your CoClass. And since COM had no idea where the CoClass lived, it never tried to load your assembly.

However, in this case HRESULT 0x80131040 is FUSION_E_REF_DEF_MISMATCH, which means that COM did attempt to create an instance of your class using the CLR. In order to figure out why that didn't work, it would be interesting to find out what was in the regsitry to correspond to the GUID you were trying to activate.

-Shawn
Asim_DIT
Hi Shawn,

It was working OK without the GuidAttribute - it seemed to generate a new GUID on each build rather than using the fixed value, meaning that the registry was full of spurious values. This may be a red herring though - I was working on different versions of the component, regasm'ing /codebase from different locations, so it probably got a bit confused.

I'm afraid I didn't take a copy of the registry before fixing it, but if this happens again I can post something on here.

What I was wondering though, as I'm getting a fusion error, is why I couldn't use the fusion log to debug the issue - why could I see no log events, not even for other C# objects that were successfully being used by the COM application

Thanks for your time!
Gary
FUSLOGVW.exe - doesn't work when used with COM?

Answer this question