Partial Solution to my 0x8000FFFF error

For those of you that might remember my post about a catastropic error I was getting, I want to follow up on the problem.  I have spent a few hours over the last couple of weeks on this issue.  I finally set down and called Microsoft Developer Support on Monday afternoon.  Three hours later, I have a partial answer.  There is a bug in certain situations in Windows 2000 and in all situations of Windows 2003 Server that I have run into.  The bug involves the loading of the VB6DEBUG.DLL.  On working with support, we came across the fact that the DLL is not being loaded when a request is being made against the COM+ objects loaded in a debug session.  I can move the VB6DEBUG.DLL file into the path and that removes the problem with the catastrophic error, but there are still a number of items that will not correctly debug.  Ah, the joys of VB6 & COM+................

Wally

5 Comments

  • Ugh, VB6DEBUG.DLL



    Like an old girlfriend, I have forgotten all about that little tart, but just the mention of it brings back terrible memories and awkwardness.

  • I've added this comment into your latest post, so I can track it. :)



    Add all the dependent components into your solution for debugging.



    We have to do this under MTS and I think COM+ is the same.

  • Blair,



    Thanks for your suggestion, but all of the components are a part of the vb group.



    Wally

  • Another problem I've had relates to having components registered in different directores.



    If you think you had this problem, then unregister all versions of components, recompile your dll's, and re-add to COM+.



    Make sure you install from where you compiled the dll's.

  • I have the same problem. What do you mean "I can move the VB6DEBUG.DLL file into the path"?

Comments have been disabled for this content.