Debug ASSERT in RegSvr32 -- bug or setup problem? 
Author Message
 Debug ASSERT in RegSvr32 -- bug or setup problem?

    Everytime I try to register a MFC ocx built in debug mode (both ASCI
and Unicode), I get an assert in regsvr32.exe.  This happens even with
an unmodified, app wizard generated OCX project.  It works fine for any
release builds.  This problem first started cropping up with the
shipping version of Visual Studio 6.0 Enterprise SP 1, possibly after
installing the last beta of IE5.0.  I've since uninstalled Visual
Studio, re-installed and layed down service pack 3.  It still happens.
    It works fine for ATL too -- just not debug MFC created objects.

    Does anyone have an idea where to look or what might be broken?

Specifically, the error message first comes up with :

Debug Assertion Failed!
Program: c:\WINNT\system32\REGSVR32.EXE
File: cmdtarg.cpp
Line: 52

    If I click the "Retry" button to debug, I get the following
assertion:
Debug Assertion Failed!

Program: c:\WINNT\system32\REGSVR32.EXE
File: dllole.cpp
Line: 126

    Finally, if I click the "Retry" button for the second time, it comes
back with an application error:
The instruction at "0x5f499d6f" referenced memory at "0x1001ab08".  The
memory could not be "read".



Mon, 19 Nov 2001 03:00:00 GMT  
 Debug ASSERT in RegSvr32 -- bug or setup problem?
The ASSERT is actually coming from the OCX. NOT RegSvr32. It's just that
RegSvr32 does a GetModuleName(NULL). One reason might be if you're using
__declspec(thread) for any variables.

-Andy


Quote:
>     Everytime I try to register a MFC ocx built in debug mode (both ASCI
> and Unicode), I get an assert in regsvr32.exe.  This happens even with
> an unmodified, app wizard generated OCX project.  It works fine for any
> release builds.  This problem first started cropping up with the
> shipping version of Visual Studio 6.0 Enterprise SP 1, possibly after
> installing the last beta of IE5.0.  I've since uninstalled Visual
> Studio, re-installed and layed down service pack 3.  It still happens.
>     It works fine for ATL too -- just not debug MFC created objects.

>     Does anyone have an idea where to look or what might be broken?

> Specifically, the error message first comes up with :

> Debug Assertion Failed!
> Program: c:\WINNT\system32\REGSVR32.EXE
> File: cmdtarg.cpp
> Line: 52

>     If I click the "Retry" button to debug, I get the following
> assertion:
> Debug Assertion Failed!

> Program: c:\WINNT\system32\REGSVR32.EXE
> File: dllole.cpp
> Line: 126

>     Finally, if I click the "Retry" button for the second time, it comes
> back with an application error:
> The instruction at "0x5f499d6f" referenced memory at "0x1001ab08".  The
> memory could not be "read".



Mon, 19 Nov 2001 03:00:00 GMT  
 Debug ASSERT in RegSvr32 -- bug or setup problem?
    This occurs with an unmodified app wizard generated MFC OLE control,
accepting all the defaults.    I did a search through the generated code for
__declspec(thread), and it does not show up in any of the code.  Neither
does __declspec.   Any other ideas?


Quote:
> The ASSERT is actually coming from the OCX. NOT RegSvr32. It's just that
> RegSvr32 does a GetModuleName(NULL). One reason might be if you're using
> __declspec(thread) for any variables.

> -Andy



> >     Everytime I try to register a MFC ocx built in debug mode (both ASCI
> > and Unicode), I get an assert in regsvr32.exe.  This happens even with
> > an unmodified, app wizard generated OCX project.  It works fine for any
> > release builds.  This problem first started cropping up with the
> > shipping version of Visual Studio 6.0 Enterprise SP 1, possibly after
> > installing the last beta of IE5.0.  I've since uninstalled Visual
> > Studio, re-installed and layed down service pack 3.  It still happens.
> >     It works fine for ATL too -- just not debug MFC created objects.

> >     Does anyone have an idea where to look or what might be broken?

> > Specifically, the error message first comes up with :

> > Debug Assertion Failed!
> > Program: c:\WINNT\system32\REGSVR32.EXE
> > File: cmdtarg.cpp
> > Line: 52

> >     If I click the "Retry" button to debug, I get the following
> > assertion:
> > Debug Assertion Failed!

> > Program: c:\WINNT\system32\REGSVR32.EXE
> > File: dllole.cpp
> > Line: 126

> >     Finally, if I click the "Retry" button for the second time, it comes
> > back with an application error:
> > The instruction at "0x5f499d6f" referenced memory at "0x1001ab08".  The
> > memory could not be "read".



Tue, 20 Nov 2001 03:00:00 GMT  
 Debug ASSERT in RegSvr32 -- bug or setup problem?
Yes,

Load RegSvr32.exe as a workspace in MSDEV.  Change the command line options
in the debug tab to register the OCX.  Now also place the path to the OCX in
the Additional DLLS list.  Set a breakpoint the DllRegisterServer() function
in the OCX.  Now hit "Start Debug" and it'll breakpoint in
DllRegisterServer() and you can step through the code and find the problem.

-Andy


Quote:
>     This occurs with an unmodified app wizard generated MFC OLE control,
> accepting all the defaults.    I did a search through the generated code
for
> __declspec(thread), and it does not show up in any of the code.  Neither
> does __declspec.   Any other ideas?



> > The ASSERT is actually coming from the OCX. NOT RegSvr32. It's just that
> > RegSvr32 does a GetModuleName(NULL). One reason might be if you're using
> > __declspec(thread) for any variables.

> > -Andy



> > >     Everytime I try to register a MFC ocx built in debug mode (both
ASCI
> > > and Unicode), I get an assert in regsvr32.exe.  This happens even with
> > > an unmodified, app wizard generated OCX project.  It works fine for
any
> > > release builds.  This problem first started cropping up with the
> > > shipping version of Visual Studio 6.0 Enterprise SP 1, possibly after
> > > installing the last beta of IE5.0.  I've since uninstalled Visual
> > > Studio, re-installed and layed down service pack 3.  It still happens.
> > >     It works fine for ATL too -- just not debug MFC created objects.

> > >     Does anyone have an idea where to look or what might be broken?

> > > Specifically, the error message first comes up with :

> > > Debug Assertion Failed!
> > > Program: c:\WINNT\system32\REGSVR32.EXE
> > > File: cmdtarg.cpp
> > > Line: 52

> > >     If I click the "Retry" button to debug, I get the following
> > > assertion:
> > > Debug Assertion Failed!

> > > Program: c:\WINNT\system32\REGSVR32.EXE
> > > File: dllole.cpp
> > > Line: 126

> > >     Finally, if I click the "Retry" button for the second time, it
comes
> > > back with an application error:
> > > The instruction at "0x5f499d6f" referenced memory at "0x1001ab08".
The
> > > memory could not be "read".



Tue, 20 Nov 2001 03:00:00 GMT  
 Debug ASSERT in RegSvr32 -- bug or setup problem?
You may want to set the assert mode (can't remember the function call)
to tell VC++ to break into the de{*filter*} immediately on an assert - I think
that's an option. Or, capture your OCX with the de{*filter*} so that you can
break in when the assert happens. Or, capture the OCX with the de{*filter*}
and set a breakpoint on cmdtarg.cpp, line 52.

Somehow you need to get into the de{*filter*} so that you can view the
call stack, variables, etc.

Have you looked at cmdtarg.cpp? That would tell you what the assert was
checking. It's in the MFC source code.

Quote:

>     Everytime I try to register a MFC ocx built in debug mode (both ASCI
> and Unicode), I get an assert in regsvr32.exe.  This happens even with
> an unmodified, app wizard generated OCX project.  It works fine for any
> release builds.  This problem first started cropping up with the
> shipping version of Visual Studio 6.0 Enterprise SP 1, possibly after
> installing the last beta of IE5.0.  I've since uninstalled Visual
> Studio, re-installed and layed down service pack 3.  It still happens.
>     It works fine for ATL too -- just not debug MFC created objects.

>     Does anyone have an idea where to look or what might be broken?

> Specifically, the error message first comes up with :

> Debug Assertion Failed!
> Program: c:\WINNT\system32\REGSVR32.EXE
> File: cmdtarg.cpp
> Line: 52

>     If I click the "Retry" button to debug, I get the following
> assertion:
> Debug Assertion Failed!

> Program: c:\WINNT\system32\REGSVR32.EXE
> File: dllole.cpp
> Line: 126

>     Finally, if I click the "Retry" button for the second time, it comes
> back with an application error:
> The instruction at "0x5f499d6f" referenced memory at "0x1001ab08".  The
> memory could not be "read".

--
.Bruce Dawson, Cavedog Entertainment.
Makers of Total Annihilation - http://www.*-*-*.com/


Tue, 20 Nov 2001 03:00:00 GMT  
 Debug ASSERT in RegSvr32 -- bug or setup problem?
    It never gets to the DllRegisterServer function.  I started the debug at
the initInstance method.  It looks like it's breaking in
pThis->OnResetState() method inside COleControl::XPersistMemory::InitNew.
When I'm debugging, I attempt to step into the
COleControlModule::InitInstance, but the "step into" command always throws
me into the COleControl::XPersistMemory::InitNew.  I've tried stepping into
the pThis->OnResetState() method, but it immediately throws the ASSERT.
    The ASSERT is being thrown at line 52 of cmdtarg.cpp.  That is the
destructor of the CCmdTarget object.  Below is the code.  m_dwRef = 2 at
this point, where it should be <= 0 according to the ASSERT.
    Stepping into these methods is throwing me all over the place -- I can
see on the disassably code where it should be executing one method, but
stepping into it I end up at another method.
    If I debug the exact same source code on another computer (that does
registers the control properly), stepping into a function while in debug
mode behaves predictably.  This would seem to suggest that the souce code
and the actual library do not match.  I have tried replacing the entire vc98
directory on the broken computer with the one from the working computer, as
well as replacing mfc*.* in the system32 directory.

CCmdTarget::~CCmdTarget()
{
#ifndef _AFX_NO_OLE_SUPPORT
 if (m_xDispatch.m_vtbl != 0)
  ((COleDispatchImpl*)&m_xDispatch)->Disconnect();
 ASSERT(m_dwRef <= 1);
#endif
#ifdef _AFXDLL
 m_pModuleState = NULL;
#endif

Quote:
}



Quote:
> Yes,

> Load RegSvr32.exe as a workspace in MSDEV.  Change the command line
options
> in the debug tab to register the OCX.  Now also place the path to the OCX
in
> the Additional DLLS list.  Set a breakpoint the DllRegisterServer()
function
> in the OCX.  Now hit "Start Debug" and it'll breakpoint in
> DllRegisterServer() and you can step through the code and find the
problem.

> -Andy



> >     This occurs with an unmodified app wizard generated MFC OLE control,
> > accepting all the defaults.    I did a search through the generated code
> for
> > __declspec(thread), and it does not show up in any of the code.  Neither
> > does __declspec.   Any other ideas?



> > > The ASSERT is actually coming from the OCX. NOT RegSvr32. It's just
that
> > > RegSvr32 does a GetModuleName(NULL). One reason might be if you're
using
> > > __declspec(thread) for any variables.

> > > -Andy



> > > >     Everytime I try to register a MFC ocx built in debug mode (both
> ASCI
> > > > and Unicode), I get an assert in regsvr32.exe.  This happens even
with
> > > > an unmodified, app wizard generated OCX project.  It works fine for
> any
> > > > release builds.  This problem first started cropping up with the
> > > > shipping version of Visual Studio 6.0 Enterprise SP 1, possibly
after
> > > > installing the last beta of IE5.0.  I've since uninstalled Visual
> > > > Studio, re-installed and layed down service pack 3.  It still
happens.
> > > >     It works fine for ATL too -- just not debug MFC created objects.

> > > >     Does anyone have an idea where to look or what might be broken?

> > > > Specifically, the error message first comes up with :

> > > > Debug Assertion Failed!
> > > > Program: c:\WINNT\system32\REGSVR32.EXE
> > > > File: cmdtarg.cpp
> > > > Line: 52

> > > >     If I click the "Retry" button to debug, I get the following
> > > > assertion:
> > > > Debug Assertion Failed!

> > > > Program: c:\WINNT\system32\REGSVR32.EXE
> > > > File: dllole.cpp
> > > > Line: 126

> > > >     Finally, if I click the "Retry" button for the second time, it
> comes
> > > > back with an application error:
> > > > The instruction at "0x5f499d6f" referenced memory at "0x1001ab08".
> The
> > > > memory could not be "read".



Tue, 20 Nov 2001 03:00:00 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. URGENT: 98 to NT4.0 change causes RegSvr32 Assert Failure

2. Porting VC5 to VC6: Assert error in Debug, no problem in Release

3. Debug.Print vs Debug.Assert

4. How to debug regsvr32

5. Debug.Assert in MC++

6. DEBUG ASSERT Error????

7. CSingleLock asserts in debug mode

8. 7.0 bug - bad ASSERT in CControlBar::SetBarStyle

9. database exception causes debug assert in CdbDBEngine

10. setup SQL extended stored procedure debugging

11. remote debugging (not setup correctly?)

12. ASSERT - Disabling them in MFC when DEBUGGING

 

 
Powered by phpBB® Forum Software