I am working with a series of DLLs that are loaded as individual CView classes in a MFC application using LoadLibrary from WinBase.h.
Building for release works and all the various DLLs load. However, when I do a debug build with Visual Studio 2010, one (and only one) of the DLLs fails to load. All the DLLs are similarly designed. Using the debugger, I can see that LoadLibrary is getting error 998 (ERROR_NOACCESS, Invalid access to memory location.). I turned on break at access exception and the bad access appears to occur within the strcmp assembly at the instruction cmp al, [ecx] (ecx is 6D655277 at this point).
However, I am not sure how to further track down this bug (and Visual Studio tends to crash whenever I break at the access violation, making it even harder).
Any suggestions or past experiences are much welcome.
Related
I've built a 64 bit version of the OpenH264 DLL in debug mode (with no compiler optimisations) and am calling it in C# (via Unity). I'm using Visual Studio 2017 to attach to the running Unity process and debug my dll.
I can place breakpoints and step through the code, however all values for the code seem to be random (or sometimes null).
For example this is where the debugger reports NULL as the value of a pointer but is stopped on the line after a failed NULL check.
Why is this happening and what can I do to get correct values when inspecting variables?
Maybe due to "At this time, Visual Studio Tools for Unity only supports managed DLLs. It does not support debugging of native code DLLs, such as those written in C++."
1 Please try to switch the Common Language Runtime Support under Configuration Properties :
2 Another potential reason is that the variable is not in the current context:
While debugging, Visual Studio will keep track of every variable in the current context
I write a c++ program using visual studio 2015 community in windows 7(64bit).
When I begin to run the program, sometimes the program will terminate, and a dialog box shows up, saying
"Application failed to initialize properly 0xc0000018".
Why do I get this error sometimes rather than always?
Thanks a lot.
Besides a bad application itself (that should be possible to track in the debugger):
This might be a corrupted Windows installation or Windows registry as well. Do you see it only for your application or also for some other applications?
It might be caused e.g. by some DLL that is built to be installed at fixed address, it might be a virus, malware, or even antivirus getting into the way.
Some of the reasons/solutions are mentioned e.g. here: https://superuser.com/questions/610495/the-application-was-unable-to-start-correctly-0xc0000018-windows-8-x64
The first thing to try is to remove the contents of APPINIT_DLLS in the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\WindowsNT\CurrentVersion\Windows - some of the DLLs loaded there might cause the problem.
The reason you do not see it every time could be that sometimes there might be some other DLL loaded on the particular address before the DLL with the fixed address requirement is to be loaded, so the conflict only occurs then.
I'm using Windows 8.1 64-bit with Visual Studio 2013 Ultimate. I am porting a program from Linux to Windows which uses C++, OpenGL and SDL. I have the appropriate libraries custom compiled through cmake on 64-bit on Windows. When I run the program from Visual Studio, the IDE says there's a head corruption. This is no surprise since I'm using pointers to instantiate objects, and I'm using raw pointers which I do plan to change to smart pointers for the sake of the argument. I'll be doing the boost magic later.
In the meantime, I used my Linux computer to diagnose any memory leaks through Valgrind and there was nothing serious reported from Valgrind. I then proceeded to use CppCheck but there was nothing serious on there either. Maybe I'm being too lenient here and Windows might actually be taking the less serious stuff more serious than Linux does, which is a surprise since MSVC tends to be more forgiving than GCC.
So, the program works on Linux and it doesn't on Windows. (Just great!) And Visual Studio isn't helping by throwing exceptions all over the place which makes me hate Windows even more. I started googling around for a solution and came across this thing called gflags or page helper, so I installed the debugging tools and tried to launch gflags but I have no idea how to use it! I then later found that you had to use some other tool called adp and then attach gflags to it, so when I launched adp it crashes. So now I have no idea what to do and am on the verge of aborting the port (which is funny since many people are complaining how hard it is to port programs from Windows to Linux while the opposite is true).
So, now I appeal to this community for help: how do I debug/diagnose heap corruption errors that occur on Windows but not on Linux? Am I really supposed to be using gflags or should I just use my guts on this?
Use the debug heap and call this at the very beginning in main().
_CrtSetDbgFlag(_CRTDBG_CHECK_ALWAYS_DF);
It will slow down the program a lot but it should break as soon as corruption occurs.
Refer to this article for details: https://msdn.microsoft.com/en-us/library/974tc9t1.aspx#BKMK_Check_for_heap_integrity_and_memory_leaks
The #Carlos's solution is perfect for smaller problems. But for huge problems, the resulting slow down is sometimes something you cannot stomach.
In this case, one can place
ASSERT(_CrtCheckMemory());
somewhere in the code, where one suspects the problem already to be present. This command checks the heap at (and only at) the spot it is inserted, and not after every new or delete call as in the case of _CRTDBG_CHECK_ALWAYS_DF. This keeps the execution time reasonable, compared to option _CRTDBG_CHECK_ALWAYS_DF.
One can find the problematic line of code pretty quickly by using a binary search kind of approach for placing the asserts.
However, sometimes _CrtSetDbgFlag(_CRTDBG_CHECK_ALWAYS_DF) and/or _CrtCheckMemory() aren't able to detect problems. Then using gflags is another possibility, which is able to show where the heap-corruption happens. In a nutshell:
enable page heap (usually you would need admin's priveleges), e.g.:
"C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\gflags.exe" /p /enable <full_path_to_exe_to_debug.exe> /full
there will be a report, that heap checks for exe_to_debug.exe were activated.
run program in debugger. Accesses out of bounds, which would corrupt the heap lead now to access violation and are easily seen in the the debugger.
disable page heap once debugging is done, e.g.:
"C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\gflags.exe" /p /disable <full_path_to_exe_to_debug.exe>
programs with activated heap check can be listed via
"C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\gflags.exe" /p
I compiled a program using freeglut, optix, cuda and other libraries (some of them dinamically loaded). It compiles and runs without problems in Visual Studio but it crashes if I execute it outside Visual Studio. Both release and debug versions work within VS, they both crash without any information on Windows 8 if I try to execute them directly.
I already included all the necessary DLLs, that didn't work.
What could be the problem?
Most such observations are usually coming from undefined behavior -- using uninitialized variable, dangling pointers/refs, overrunning buffer.
You may try to use Application Verifier, with some luck it might rearrange the used memory enough for you to trigger the problem under debug to help corner it.
Also, when it crashes you should get a prompt to launch VS and inspect the problem -- did it not indicate a hint? What was the immediate cause of the crash and what you had on the call stack there?
You can try comparing the environments between visual studio and the default environment.
Dependency walker should identify any missing DLLs.
Get WinDBG, then File > Open Executable and run the program under WinDBG. When it crashes, you will get some more information. My answer here describes an issue in .net, but the concept applies to native C++ as well.
Visual studio runs executables under "debug" mode, meaning a debugger is present.
What does this mean? If you check out the msvcrt implementation, if the runtime detects a debugger is present (IsDebuggerPresent), then heaps preform differently.
What does this mean? It means buffer sizes are "nudged" upwards, it means memory allocations are wiped clean by default (no need to memset), etc.
This can cause a variety of bugs to manifest, or some more subtle bugs to be hidden.
I developed MFC Regular DLL "Static Linked" using vs2005. when compiled it as 32-bit DLL
I can load it using "LoadLibrary" from my machine or from any other machine.
but when compile it as 64-bit DLL I can only load it from my machine.
I review my code and found global object declared.
MyClass myObj;
when I comment this object..I can load DLL and use it from diffrent machine.but when any
global object found...I can't load my DLL from diffrenet machine.
anyone can help me?
when I try to use "GetLastError" it return number like "-529697949"
The error code is 0xe06d7363, the last 3 hex digits spell "MSC". That's the exception code for a C++ exception in Microsoft's compiler.
Your code is bombing on a uncaught C++ exception, probably thrown in DllMain(). You'll need a debugger if you can't reverse-engineer it from this hint.
Does the target machine have the 64bit Visual C++ 2005 redistibutable installed? It's possible they have the 32 bit version installed from other application but that the 64 bit one has never been installed?
See http://www.microsoft.com/downloads/en/details.aspx?FamilyID=90548130-4468-4bbc-9673-d6acabd5d13b
The uncaught C++ exception can also be thrown while the global/static objects of your dll are created/allocated/initialized (which is part of DllMain). So there is a good chance that somewhere in the code a valid throw statement is responsible for this behaviour (rather than some compiler/architecture/platform bug; maybe its just a define that is x64 specific?).
To find that nasty little *#!!:
Compile all your code with debug information (/DEBUG)
Turn on the Symbol Server (Debug/Options/Debugging/Symbols/Symbol file (.pdb) locations: [x] Microsoft Symbol Servers)
Turn on all Break on Exceptions (Debug/Exceptions.../ Tick all [] in the "Thrown" column)
Start Debugging and you will eventually find the correct place.
Due to the missing enforced "throws" statement like e.g. in Java (in c++ its optional and pretty useless; see Throw keyword in function's signature ), the try/catch/throw system is hardly usable to create robust and maintainable code; its almost like hiding random gotos everywhere.