Before creating a dll i have placed OutputDebugString throughout the code so that i can see the exact function where the dll maybe failing. Now i have created a visual studio project which loads this dll using LoadLibrary function.The loadlibrary call is successful but i cannot see any of the output debug string when i use WinDBG to debug the EXE.According to me I should see at least the output debug string which is near the code where the dll starting point is present.Can anybody tell me what maybe the problem?
Further info:-
The dll contains c++ code and is a 64 bit dll.
I am using visual studio 10 and the OS i am using is Windows 7 64 bit.
The WinDBG is also 64 bit.
Related
I am investigating a crashing program but cannot load symbols for native image DLLs in Visual Studio 2013. The application is 32-bit and uses .NET 4.0.30319. I confirmed this by checking what version of clr.dll is loaded into process from the modules window. Also from the modules window, I checked where mscorlib.ni.dll was loaded from:
clr.dll C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
mscorlib.ni.dll C:\Windows\assembly\NativeImages_v4.0.30319_32\mscorlib\ce5f61c5754789df97be8dc991c47d07\mscorlib.ni.dll
I was able to successfully generate the PDB for mscorlib.ni.dll:
but when I try to load it into VS 2013 by right clicking on the stack frame for mscorlib.ni.dll and selecting Load Symbols, I get a messaged that says "A matching symbol file was not found in this folder."
I have looked through:
Creating Ngen Pdbs for Profiling Reports/
And followed the simple instructions for generating the PDB because I just want to see function calls at this point,
Get the right .net native symols for Windbg
How to get the PDB file for mscorlib.ni.lib (.Net Framework 3.5)
It looks like the most common source of error is choosing the correct bitness. I know from the modules tab that I am loading the 32-bit variant of mscorlib.ni.dll and again from my screenshot, you can see that I am using the same version of the the .NET framework and the 32-bit version of Ngen.exe. I tried this for WindowsBase.ni.dll and saw the same behavior where I was successfully able to generate the PDB but could not load it.
I have the debugger enabled to Just-in-time debug Managed and Native code.
Questions:
Am I using the wrong version of ngen.exe on to create this PDB?
What does Visual Studio check when it tries to load a PDB?
Is there some other setting I need to enable in VS to debug this type of code?
Thanks!
A VC++ 2008 win32 console application uses some MFC functions, it can run without problem in 'Debug' mode within the VC++ 2008 environment. Also, the debug executable can ran on any computer with full version of visual studio 2008 installed.
But that same debug executable won't run on systems that don't have the visual studio 2008 installed, it gives the following error message:
The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.
The initial search for this problem leads to MSN recommendation to install the VC++ 2008 x86 redistributable SP1. But this failed to resolve the problem.
Then, the win32 console application is recompiled for 'Release' mode and it gives the following error message:
fatal error C1189:#error: Building MFC application with /MD[d](CRT dll version) requires MFC shared dll version. Please #define _AFXDLL or do not use /MD[d]
this error happens in afx.h header.
I tried to actually #define _AFXDLL in preprocessor, but it created new errors about unable to convert MFC type of string to char* etc
I also tried 'Use of MFC' settings: in static library and shared DLL, both create more errors
The thing is, the original program was created in VC++ 6.0 and it used a lot of MFC functions (especially string and CObject), but after recompile in VC++ 2008 in a win32 console app, it somehow can work in debug mode, but can't be stand-alone exe in release mode, which is kinda what I need to have a stand-alone exe that can run on newer windows (7 or 8)
Could anyone help. Thanks.
Yes. Don't build in Debug mode. Build for Release. You can't legally distribute the Debug DLLs. You can build a Release version with Debugging information in it--via PDB files.
This may also happen if your release build has dependencies against some debug libraries, link against non debug ones.
I have a solution (Visual Studio 2008) that contains a couple of products. One of these products contains a control that was developed by a colleague that requires loading of a dll. The dll must be loaded when the solution is loaded so that I can view and use the control. However, I am getting errors in the error window saying the control is not defined. When I look on another system (Windows XP Pro) that has VS installed and uses this product and dll, it works fine. However, when I try to load it on my system (Windows 7), I get the errors.
I used Process Explorer on both systems to verify that the dll in question is being loaded. On the XP system where everything works fine, I can see the dll needed is being loaded from C:\windows\system32. I have the dll in the same location (c:\windows\system32) on my Windows 7 box. However, when I load the solution on the Windows 7 box, I can see through Process Explorer that the dll does not load. I know c:\windows\system32 is in the path and I can see other dlls from windows\system32 have been loaded by the visual studio executable image. Why wouldn't this dll be loading? Is there some logging mechanism within VS that will tell me at load time (when I load the project containing the control) why the dll will not load?
Is this a Windows 7 thing? Should I not be putting a developed dll in windows/system32?
Help is appreciated.
Thanks.
Hmm the only thing i have in mind is if the .dll is 32bits and you are making a 64bits application they could be incompatible.
One handy trick I use all the time to deal with dll loading issues is to turn on fusion logging. With that, loading exceptions will be logged to a file, where you can see what might be missing or where the framework is probing for it.
To turn it on, set the following registry keys:
HKLM\Software\Microsoft\Fusion\ForceLog registry value to 1 and HKLM\Software\Microsoft\Fusion\LogPath registry value to C:\FusionLogs (this path must exist)
More info on it:
http://www.hanselman.com/blog/BackToBasicsUsingFusionLogViewerToDebugObscureLoaderErrors.aspx http://msdn.microsoft.com/en-us/library/e74a18c4(v=VS.90).aspx
How can we trace a compiled application from windows 7. I can see in the event viewer that some DLL files which my program is trying to fetch are causing problems but I can't figure out why.(This is with qtcored4.dll)
You can solve DLL loading problems with Dependency Walker, either by looking at the exe (just open it) or tracing DLL load process by starting profile.
I have a .dll file produced with Visual Studio 2005 (unmanaged C++). In various functions within the DLL, I can detect errors and call another function within the DLL to produce a minidump (using dbghelp.dll) .
This works perfectly when the application using the DLL is also a VS2005-produced program. However, when I use National Instrument Measurement Studio/CVI to produce the application (in plain C, not that it should matter), it does not get a .pdb file (surprise!). As a result, when I open the generated .dmp file with VS2005, it tells me the application was not built with debugging (but it was!) and the stack shown is useless.
Many (40+) other functions in this DLL are successfully used by the CVI application. This would seem to demonstrate the successful access of the DLL functions from the non-VS application.
National Instruments apparently can use a full dump from DrWatson, so it must be possible.
Does anybody know how to get what is needed for using the .dmp file?
To summarize: No .NET, function access is fine, generated minidump files do not seem usable by Visual Studio.
Thanks for your help.
You must have symbols (at least dllexports) to be able to analyze the dump file. Try use Debugging Tools for Windows (WinDBG) to open the minidump file and see what you've got. WinDBG does a much better job analyzing dumps than VisualStudio 2005.