Dependency walker msvcr80d.dll missing coredll.dll and dwmapi.dll

[phnimx]

I've completed migrating one of our company's C++ Managed Code
applications to VS2005. I'm now attempting to run the application but there
seems to be problems when accessing an object that is properly exported from
a utility dll of ours. The dll is written in MFC with sections of C++
Managed Code.

The dll exports its objects in the same manner as any VS2005 Solution Wizard
driven win32 dll base code, using the model: __declspec(dllexport).

In fact when I peer into the dll with the DepedencyWalker app, the exports
are readily visible.

I copied msvcr80d.dll into the dll's folder before implementing
DepedencyWalker app on the dll.

DepedencyWalker complains that msvcr80d.dll requires coredll.dll and
dwmapi.dll.

This seems strange because the dll is NOT targeted for any embedded
platforms, it's targeted for x86 platforms only.

Further, when I attempt to step into the new(ing) up of the first object in
the dll, I get the following message:

"Managed Debugging Assistant 'FatalExecutionEngineError' has detected a
problem in C:\MyApp\MyApp.exe.

Additional Information: The runtime has encountered a fatal error. The
address of the error was at 0x79e7edd5 on thread 0xa20. The error code is
0x00000005. This error may be a bug in the CLR or in the unsafe or
non-verifiable portions of user code. Common sources of this bug include
user marshaling error for COM-Interop or PInvoke, which may corrupt the
stack."



I'm not an expert in COM-Interop but I believe C++ Managed Code leverages
just that to accomplish its .NET integration magic.

Can you provide me with any information on the above issues?

Can you provide me with the basics and the gotchas with regard to dll
exports and general access or a dlls methods and/or objects?

Thanks

Phnimx

 

[Jeffrey Tan[MSFT]]

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.

 

[phnimx]

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

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.

 

[Jeffrey Tan[MSFT]]

Hi Phnimx,

Thanks for your feedback.

With the current information available it is hard to give a definite answer
to resolve this problem.

Do you use any MFC extension dll in your project? There may be some
problems if you are using an MFC Extension DLL from a MFC Regular DLL,
please refer to the KB below:
"You may encounter one or more related problems when you use an Extension
DLL from a Regular DLL in Visual C++"
http://support.microsoft.com/kb/154126

As you can see in the second item, "Resources stored in the Extension DLL
fail to load because AfxFindResourceHandle returns NULL or an incorrect
resource handle". The thread below also confirms this suspicion, I hope you
are the same problem:
http://groups.google.com/group/microsoft.public.vc.mfc/browse_frm/thread/1f8
9e22a1cb2d0ab/ec43df099de3f11d?lnk=st&q=%22Debug+assertion+in+file%3Aafxwin1
.inl+line%3A22%22&rnum=1#ec43df099de3f11d

Additionally, I recommend you provide the stack trace of this failure. It
may be useful to look at the stack trace.

Finally, is it possible for you to create little sample project
demonstrating this problem? If I can give it a local reproduce, I can
understand it better and give it a troubleshooting.

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.

 

[phnimx]

Hi Jeffrey,
Thanks for the information. I'd be happy to send you the source. Is there
a secure method for doing so?
Regards,
Phnimx

 

[Jeffrey Tan[MSFT]]

Hi Phnimx,

You may send it to me by (e-mail address removed)(remove "online.").
Note: I would recommend you to send a little sample project for me to
reproduce this problem, since large full source project will cost a lot of
time to narrow down and is not suitable to support in newsgroup. Thanks for
your understanding.

I will wait for it. 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.

 

[phnimx]

Hi Jeff,
I had one of my developers send you a small program that reproduces the
problem.
Did you receive it and are you able to reproduce the problem?
Regards,
Phnimx

 

[Jeffrey Tan[MSFT]]

Hi Phnimx,

Sorry for the late response. You sent the project to me at the weekend, so
I got it until now.

Yes, I got the sample project. However, there are some problems in it:
1. Your developer sent a large project to me instead of a little sample
project. There are more than 30, 40 .cpp/.h files in the DNPUI project. So
there are too much details which will confuse the specific problem. I would
recommend you to create a just reproduce sample project for this issue, so
that I can place my focus in the specific problem.

2. When I compile the DNPUI project, I will get the error below:
Error 1 fatal error C1192: #using failed on 'c:\Documents and
Settings\v-jetan\Desktop\sample
projects\VS2005DLLIssue\DLLIssue\TestDNPDll\DNPUI\cmi.communication.compinte
rface.dll' c:\Documents and Settings\v-jetan\Desktop\sample
projects\VS2005DLLIssue\DLLIssue\TestDNPDll\DNPUI\StdAfx.cpp 1

I will wait for your further sample project. 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.

 

[phnimx]

Hi Jeffrey,
We updated the sample, dramatically reducing the size and removed the
references to satellite assemblies in the DNPUI dll.
I instructed the same developer to email you the update.
Did you receive it and is the size to your satisfaction?
Are you able to reproduce the problem?
Regards,
Phnimx

 

[Jeffrey Tan[MSFT]]

Hi Phnimx,

Thanks for your feedback!

Yes, I have received the reduced sample project from your developer Philip.
I can reproduce this error in it. I have discussed with one developer from
VC++ team internally, below is his comment:

"You've got serious problems here.

You're using MFC and old-syntax CLR. I'm not even sure that is supported.
In any case, it is a very tricky business. You've upgraded the project from
a previous version of VC. I suspect not all of the settings got upgraded
correctly. You're exporting an entire class instead of individual
functions. Again, this is very tricky and not usually a good idea. You're
not properly initializing the CRT for your DLL. And finally, as I mentioned
before, you aren't initializing MFC for your DLL. MFC needs to be in
control of the entry point for MFC-based DLLs, but this DLL is set to
/NOENTRY.

I suggest starting over. Use the VC 2005 wizard to create a new C++ MFC DLL
project, then follow the instructions from MSDN on how to make this work
with managed code (if you really need managed code for this project):

To compile an MFC executable or regular DLL with /clr:
1. Open the Project Properties dialog by right clicking the project in
the Solution Explorer and selecting Properties.
2. Expand the node next to Configuration Properties and select General.
In the right pane, under Project Defaults, set Common Language Runtime
support to Common Language Runtime Support (/clr).
From the same pane, make sure Use of MFC is set to Use MFC in a Shared DLL.
3. Under Configuration Properties, expand the node next to C/C++ and
select General. Make sure Debug Information Format is set to Program
Database /Zi (not /ZI).
4. Under Configuration Properties, select C/C++ and then Code
Generation. Make sure Runtime Library is set to one of Multi-threaded Debug
DLL (/MDd) or Multi-threaded DLL (/MD).

Then copy the existing code into the new project."

I have tried to remove "/NOENTRY" linker option in the "Linker"->"Command
Line", now the error disappears. You may give a try.

I have forwarded this solution to that developer and he added some further
comment below:

"Perhaps just removing /NOENTRY would work for now. But you might run into
problems with some of the other areas I mentioned. There isn't enough code
in that project to really be a problem, so I would fix the few little
syntax errors and upgrade to /clr."

Hope this helps.

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.

 

[Ben Voigt]

"Perhaps just removing /NOENTRY would work for now. But you might run into

problems with some of the other areas I mentioned. There isn't enough code
in that project to really be a problem, so I would fix the few little
syntax errors and upgrade to /clr."

That last sentence makes absolutely no sense, given that you asked the OP
for a minimal reproduction of the problem.

 

[Jeffrey Tan[MSFT]]

Hi Ben,

Yes, this is because the developer does not know the project is merely a
sample and I just pasted his comment here without modify.

Anyway, we just recommend the Phnimx to port the project with new C++/CLI
syntax.

Thanks for your comment.

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.