Re: Dependency walker msvcr80d.dll missing coredll.dll and dwmapi.dll
- From: "phnimx" <phnimx@xxxxxxxxxxxxx>
- Date: Mon, 26 Feb 2007 13:19:56 -0500
Hi Jeffrey,
Thank you for your reply. We were using the wrong msvcr80d.dll.
Using the correct one makes the coredll.dll and 'FatalExecutionEngineError'
issues disappear.
However, when attempting to acquire an object in our utility dll, I find
myself (many times) at an ASSERT in 'afxwin1.inl'
_AFXWIN_INLINE HINSTANCE AFXAPI AfxGetResourceHandle()
{ ASSERT(afxCurrentResourceHandle != NULL);
return afxCurrentResourceHandle; }
While I can ignore a number of assertions, I get to a point where every
single LoadString() in the utility dll asserts.
Our utility dll is mostly MFC based. In the linker settings
Force Symbol References = __DllMainCRTStartup@12.
This of course means that we pass the implementation of DLLMain() the MFC
framework.
The strange thing is when I set a breakpoint in CMyWinApp::InitInstance()
our CWinApp derivation class, it doesn't break?
The caller application EXE is "new"ing up a 'CUtil' class within our
utility dll. This 'CUtil' class is NOT the CMyWinApp class. The ctor of the
'CUtil' class contains the following line.
AFX_MANAGE_STATE(AfxGetStaticModuleState())
The problem seems to be that MFC can't get the resource handle to the
utility dll.
Any ideas what we're missing here?
Can you suggest any alternative methods that can help?
Thanks,
phnimx
""Jeffrey Tan[MSFT]"" <jetan@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:5cWgDEYWHHA.2208@xxxxxxxxxxxxxxxxxxxxxxxxx
Hi Phnimx,
#1, Dependency Walker problem.
This looks like a strange problem. I have searched all the internal
database and found no records reported related to it.
Are you running into this problem on the development box or a system that
does not has VS.NET
If your problem occurs in system without VS.NET 2005, then:
1. You may deploy the debug build and give it a try.
2. Make sure that the system has the VC redist (remember debug builds of
VC
Runtime are not distributable), you can check this by looking at
%SystemRoot%\winsxs folder and look out for folders containing
Microsoft.CRT, or Microsoft.MFC or Microsoft.ATL. Also note the processor
type.
Another possibility is that you found and copied the Windows CE build of
msvcr80d.dll to the directory. You may give this a check.
#2, 'FatalExecutionEngineError' problem.
Normally, FatalExecutionError managed debugging assistant (MDA) is
activated when a fatal error in the common language runtime (CLR) has been
detected. Do you get this error under VS2005 debugger? If you use the Exe
without debugging, does the problem still exist?
As far as debugger is concerned, make sure that "Debugger type" is set to
"Mixed", you can check this in the "Debugging" option of the project
properties. This should allow you to step into managed and unmanaged code.
Does this problem still exist?
I will wait for your further information. Thanks.
Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no
rights.
.
- Follow-Ups:
- Re: Dependency walker msvcr80d.dll missing coredll.dll and dwmapi.dll
- From: "Jeffrey Tan[MSFT]"
- Re: Dependency walker msvcr80d.dll missing coredll.dll and dwmapi.dll
- References:
- Dependency walker msvcr80d.dll missing coredll.dll and dwmapi.dll
- From: phnimx
- RE: Dependency walker msvcr80d.dll missing coredll.dll and dwmapi.dll
- From: "Jeffrey Tan[MSFT]"
- Dependency walker msvcr80d.dll missing coredll.dll and dwmapi.dll
- Prev by Date: Re: Handle to an opened form
- Next by Date: frustrating parameter issue
- Previous by thread: RE: Dependency walker msvcr80d.dll missing coredll.dll and dwmapi.dll
- Next by thread: Re: Dependency walker msvcr80d.dll missing coredll.dll and dwmapi.dll
- Index(es):
Relevant Pages
|
Loading