I have a printing application that is using the Printer object to print files. On one particular machine (not others), this program will crash after processing some number of files (20 or so).
The crashes always occur during a DoEvents call.
Has anyone seen anything like this?
Thanks!
I would examine the Dr. Watson and mini dump files and find out what exactly is crashing. On XP this lives in:
C:\Documents and Settings\All Users\Application Data\Microsoft\Dr Watson
In other versions of Windows, different places. Load the Minidump into a modern version of Visual Studio with the pdo (debugging symbols) of your program and you should have a pretty good idea of what is crashing. If you haven't made symbolic debug info, make a build with that. Also, make sure you are compiling to Native code and not P-Code (sometimes P-Code crashes and you can't figure out why)...
Related
I hope the question is not too vague and someone can add some light to my problem.
I created a Windows application (makefile) with the chromium project (already asked about this problem in the chromium forum) and Visual Studio 2019.
The application starts some processes and each of them used around 20 KB memory but strangely this same application uses over 200 KB per process is some PCs with same Windows version.
(Memory usage after starting the application, nothing else done)
I have been fighting a couple of days with the compiler/linker options with no success. Still huge memory usage.
Chromium examples did not show this problem using my makefile which made me even more crazy.
At the end I ended up changing the name of the exe file, instead of app.exe just app1.exe and...problem gone, normal memory usage in all PCs which shown this problem.
I changed the name in the makefile to generate same executable but with different name and also changed in Windows Explorer the name of the original and problematic exe file with same positive result.
I renamed in Windows Explorer the good app1.exe application back to app.exe and the problem appeared again...
I am searching now for some kind of Windows configuration or program which could generate this problem but no luck so far. Windows Firewall already disabled.
or could this be some kind of virus?
Problem solved...thanks to ProcessHacker tool I found out that the library "verifier.dll" was loaded in the bad case.
This dll is part of the Windows Application Verifier tool. I do not remember to have used this tool before, it is even not activated.
I then found out that there is a registry entry:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\
where I could find the name of my application. After renaming this entry everything works as expected.
I will now investigate what the variables inside this entry mean:
GlobalFlag = 0x02000000 and PageHeapFlags = 0x2
I've deployed many games over the years on Windows and always shipped the necessary SDL.dll along with the game, in the game's folder.
This has always worked fine, and continues to work for well over 99% of people.
However, I'm starting to see reports of "The code execution cannot continue because SDL.dll was not found" from a few users. They all seem to be on Windows 10. And they confirm that the DLL is indeed in the game folder as it should be, and they're running the game directly from inside the folder, and not through a shortcut that would break the working directory.
I also have reports from other Windows 10 users who are not having this problem.
I did some research and found that this kind of error can be misleading, and may be triggered if the DLL itself loads another system DLL that is not found.
I used DependencyWalker on my EXE and found the SDL.dll depends on:
ADVAPI32.DLL
GDI32.DLL
KERNEL32.DLL
NTDL.DLL
MSVCRT.DLL
USER32.DLL
WINMM.DLL
Those all seem pretty standard. Would they be missing from certain Windows 10 installs for some reason?
Other ideas is that Windows 10 is moving to a signed DLL requirement (just a guess) or that the way Windows 10 handles library load paths has changed.
But again, this is working for other people on Windows 10.
Other details: DLL and EXE are both 32-bit. The systems in question are most likely 64-bit.
In this case, it turns out to be a really stupid end-user mistake.
I'm answering it here just in case anyone else runs into it.
When a user double-clicks a ZIP file, it LOOKS like they've opened a folder and are viewing the files.
They can even run the game from inside this ZIP browsing view.
But of course, Windows can't find DLLs that are also inside the ZIP file.
Thus, this behavior on Windows is pretty confusing to end users. The solution is to extract the ZIP first before running the game.
I have a mixed managed and unmanaged C++ application that's working quite well. I'm using Visual Studio 2013 to compile it, and all is well. Recently I upgraded my computer to Windows 10, and now it's not working.
If I get the executable compiled on Windows 8, it runs properly on Windows 10. It only fails if I compile it on Windows 10.
The failure is peculiar as well. I run the EXE and nothing happens. When I run it from Visual Studio it doesn't even reach the first line of main. Breakpoints are all marked as 'disabled'. When I break the running process the debugger shows an empty stack trace.
UPDATE: Hunch about DLL loading turned into a fact:
I used Process Explorer and I see the process has two threads. The one starting at !CorExeMain is stuck at !LdrLoadDll, but I can't tell which DLL that is.
OK, found the DLL that causes the problem. I've created a C++/CLI console application, used that DLL and got the same behavior. The DLL is part of the application (and part of the VS solution). It's a native C++ DLL, compiled with the same compiler and settings. This DLL references other DLLs unfortunately.
This is a generic problem called "LoaderLock". The operating system makes very strong guarantees when it calls the DllMain() entrypoint of a DLL. Strictly in loading order, they never run at the same time. There is a lock in the OS loader that ensures these promises are kept.
And a lock always has the potential to cause deadlock. It will happen when the DllMain() entrypoint does something unwise like loading the DLL itself with LoadLibrary(). Or call a function that requires the OS to have a DLL already loaded. Can't work, its DllMain() entrypoint can't be called because the loader lock is held. The program will freeze. C++/CLI apps are prone to this problem, lots of stuff tends to happen in DllMain(). Indirectly, you can't see it in your code.
You can only see it with the debugger. You must change its flavor, Project > Properties > Debugging > Debugger Type, change it from "Auto" to "Mixed". You'll now also see the unmanaged code that is running including the OS loader functions, name starts with "Ldr". Be sure to enable the Microsoft Symbol Server with Tools > Options > Debugging > Symbols. And be sure to use the Debug > Windows > Threads debugging window as well, the truly tricky loader deadlocks that don't repeat well or appear to be affected by the OS version are caused by another thread loading a DLL.
Diagnosing and fixing it can be difficult, be sure to reserve the time you need to dig in. If you can't make heads or tails of the stack traces then post them in your question.
Before taking #Hans Passant advice I carefully combed through the code, dumpbin /dependentsed the executables and DLLs and made sure there were no custom DllMains. There were none. DLLs were indeed loaded with LoadLibrary, but that was happening long after the loading DLLs were loaded.
So I took #Hans Passant advice. Set up the debugger properly and checked the state of the process during the deadlock. One of the threads was stuck in LdrLoadDll.
It took a little tinkering to find the name of the DLL that was passed to LdrLoadDll. It was AVGHOOK.DLL .
I disabled AVG, and lo and behold - everything is back to normal.
This is the second time AVG is messing with me. The previous time I nearly replaced a printer until I figured out all the PCL errors disappeared when I disabled AVG. I think I'm not going to use it any more.
I have put our comment ping pong into a full text:
#1:
As you found out, that your application did not load, you needed to check if applications on your system (W10, VS2013) run at all.
Reply: A test console app is running fine.
#2:
If your application doesn't run, build up a similar application and step-by-step put code of your app into the new app until it fails.
If the failure is causes by a DLL (which cannot be loaded, as it was in your case), remove DLLs from your app until it works. Alternatively build a dummy console app, include DLL #1 and use some functions of that DLL. Compile, run, check. Go on until DLL #n...
Reply: faulty DLL was found.
#3:
Reference only this DLL in the test app to ensure it's this DLL only and not a combination of DLLs.
Is it a managed DLL or a native C++ DLL?
If the faulty DLL is from a foreign source: bad luck. Ask the developer for support.
If it's your own: Did you compile the faulty DLL on W10+VS2013, too, or did you copy it from your previous system? I suggest you compile this DLL again on the new system.
Reply: it's a native C++ DLL, which is part of the solution and is compiled together with the main app.
This DLL references other DLLs unfortunately.
#4:
Create a new console app, that references not your faulty application DLL, but the DLLs which are referenced by YOUR DLL. Omit the intermediate step to detect if the failure comes from the other DLLs.
The general procedure is: Split up faulty code to find out out which part is causing trouble. Romans already knew this 2000 years ago: Divide et impera ;-) Though they did it in a different context...
We had the exact same problem here during several weeks ! And we finally found a solution !
In our case, it was the anti-virus Avast which was corrupting the generated .exe !
The solution was to simply disable all agents while generating the release !
If you use another anti-virus, try to disable it.
I am making a retro text adventure game in Turbo Pascal that will be played in MS-DOS, and I want it to be in the COM file format. I've looked it up and have found nothing on this subject. If you can help me that would be greatly appreciated.
Something other than that, whenever I try to run my program (compiled into EXE) from DosBox it can't run due to "This program cannot be run in DOS mode". Is this because I'm using Turbo Pascal 7 and need to downgrade? Thanks a lot of you can figure this out.
Set your TP7 to target dos, not windows. Note that you might have an Windows only TP product (also known as TPW)
COM files will still be out of your reach, but at least DOS exe files should run in dosbox. Keep in mind that COM files have a 64k limitation, and therefore are of limited interest.
Free Pascal is working on a DOS16-bit Dos compiler that can generate com files directly from (64-bit) Windows, and while it is working, it is not released yet.
In the past, I have heard references to parsing .dmp files using WinDbg (I think - I might be wrong).
I have also done fairly extensive debugging with the help of .map files, and I have done extensive debugging using standard logical heuristics and the Visual Studio debugger.
However, occasionally, the program I am developing crashes and creates a .dmp file. I have never been able to interpret the .dmp file. A while ago, I posted a SO question regarding how to interpret .dmp files ( How to view .dmp file on Windows 7? ), but after somewhat significant effort I was unable to figure out how to interpret .dmp files using the answer to that question.
Today, I was viewing an unrelated SO question ( C++ try/throw/catch => machine code ), and a useful comment underneath the accepted answer has, once again, made reference to WinDbg.
If you really want to find this out though, it's easy - just trace
through it in WinDbg
I would like to follow this advice. However, for me, it's not easy to "just trace through it in WinDbg". I've tried in the past and can't figure out what exactly this means or what to do!
So, I'm trying again. "For once and for all", I would like to have plain-and-simple instructions regarding:
What is WinDbg
Assuming WinDbg is related to .dmp files, what exactly is a dump file and how does it relate to WinDbg (and correct me if my assumption is wrong)
How do you create .dmp files and, correspondingly, how do you use WinDbg to analyze them (again, correct me if I'm wrong about the relationship between WinDbg and .dmp files).
If you could please answer this question from the "starting point" of a programmer who ONLY has Visual Studio installed and running.
Thanks!
WinDbg is a multipurpose debugger. It can debug a live process by attaching, set breakpoints, etc like you would with any other debugger. It can also analyze crash dump files as well, which are .dmp files. It functions by you giving it commands.
A .dmp file is a memory dump of something. What that something is depends on what the memory dump is for. It could be for a process, for example. It could also be for the kernel. What is in the memory dump depends, too. In your case, it's probably what your process looked like at the time of it crashing. What the memory dump contains can vary depending on the dump type.
There are various ways. On Windows Vista+, Server 2008+ - you can do it right from the task manager. Right click the process, and click "Create Memory Dump". WinDbg can make a memory dump from a live process too by using the .dump command. Other tools like adplus can be used to automatically create a memory dump on certain conditions, like when a process exceeds a memory or CPU threshold, or when it crashes.
WinDbg can open a Crash Dump easily enough. What is important is that you get your symbols loaded correctly, first. Usually in the form of .pdb files or from a symbol server (though not necessary, or always possible, it is greatly helpful).
Once you have WinDbg running, take a look at the list of commands available to poke around in your crash dump.
WinDbg is a Gui version of the command line debugger cdb.exe, both are user-process and kernel mode debuggers, it uses DbgHelp.dll to issue commands to your application or NT kernel (you can also do the same as it has an api).
.Dmp files are memory dumps of varying detail, some can have minimal detail enough for call stacks of all threads, whilst others will put the entire user-mode memory, handle information, thread information, memory information etc.. see this for more info. So dump files have nothing to do with WinDbg, other than it can open them, incidentally you can open .dmp files in Visual Studio
Like #vcsjones has already stated you can do this using task manager (at least you can from Vista onwards), you can use procdump, you can do this once WinDbg is attached, I usually do a full mini dump like this: .dump /ma c:\mem.dmp, you can also set Windows to do this when a crash happens using Dr. Watson
However, you must have the symbols for Windows and your application in order to be able to generate sensible call stacks, note that for obvious reasons you cannot step through or set breakpoints in a a memory dump, you can only do this for a live process. You can also have WinDbg attach non invasively, so Visual Studio could be attached and you can attach WinDbg non invasively and use the toolset in WinDbg to assist debugging.
For me the main advantage of WinDbg is its free, it is a small download and install, it is fast, it has a very rich toolset for diagnosing problems that are either difficult or impossible to do using visual studio.