I got a new Windows 8 PC 4 days ago. Suddenly it rebooted. The event log shows:
The system has rebooted without cleanly shutting down first. This error could be caused if the system stopped responding, crashed, or lost power unexpectedly.
The computer has rebooted from a bugcheck. The bugcheck was: 0x00000024 (0x000000b50019060b, 0xfffff8801d326748, 0xfffff8801d325f80, 0xfffff880019041e6). A dump was saved in: C:\windows\MEMORY.DMP. Report Id: 040413-33828-01.
The file mentioned is over 2 GB. There is also a smaller file in c:\windows\minidump
My goal is just to determine what program caused the crash. How can I get that information from either the memory dump or the mindump? Or is there a better way to figure that out?
The instructions here: the instructions here: networkworld.com/supp/2011/041811-windows-7-crashes.html work for Windows 8 to interpret dumps. Thanks to roger_rowland for leading me straight to a page describing my particular problem.
Related
Trying to profile my command line application in VS 2017 on a W10 machine with April 2018 Update, VS fails to create the report.
The UI says Microsoft Visual Studio was unable to create a diagnostics report. Check Output window for errors.
The Output window says
Profiling of 'Program' started.
Program has exited.
Profiling of 'Program' stopped.
Diagnostics session stopped with errors.
Merging of ETL files has failed (0x80070070) (Flags: 0x0000011f).
Previous search gives little answers as to why, but the problem seems related to Windows' event logging service. Comments on this similar question suggest it's related to disk occupation, but with no source. My SSD is indeed almost full, but with 6 GB of free space.
I resolved the issue, the multiple times it happened, by restarting windows and then start the profiling as first thing as the OS is ready. On a fresh start it works, but going further with changes and profiling it eventually appears again.
If someone knows a long-term solution feel free to add.
Code 0x80070070 "There is not enough space on the disk." Your disk was full, or became full during a build or other operation as temporary files were created.
I have an application written in Delphi XE3 (Originally Delphi 7) with a MySQL database. It was running on 5 computers on a network. Two of the computers were on windows 7 while 3 were still windows XP. The client recently upgraded the 3 windows XP computers to windows 7 x64 (3 brand-new identical machines). The program is running fine on one of the new computers but on the other 2 I get the error message "A problem caused the program to stop working. Windows will close the program and notify you if a solution is available". The program seems to crash at the end of the FormActivate procedure after it had verified the password and connected to the database. The MySQL server is up and running. I can access the database on the problem machines locally and remotely successfully.
I have searched the Internet and some websites suggest that this error is a protective mechanism from Windows triggered by a thread to system files, indefinite loops or memory problems – none of which are applicable to my program.
I have since reformatted the 2 problem computers and reinstalled Windows 7 again but it did not solve the problem.
The DependencyWalker output on both problem and working machines (and on my development machine) are identical :
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Error: Modules with different CPU types were found.
With regard to different CPU types - in all instances the application is x86 and the rest of the modules are x64. This could be a 32-bit-64-bit problem but the program is running on all the machines except for 2 problem machines.
The Windows Event Viewer reports the following error:
Faulting application name: February_2014.exe, version: 1.0.0.0, time stamp: 0x52fa3b19
Faulting module name: KERNELBASE.dll, version: 6.1.7601.18229, time stamp: 0x51fb1116
Exception code: 0x0eedfade
Fault offset: 0x0000c41f
Faulting process id: 0x1510
Faulting application start time: 0x01cf28a57840f88d
Faulting application path: C:\dgpa dgr\February_2014.exe
Faulting module path: C:\Windows\syswow64\KERNELBASE.dll
Report Id: bd26ca27-9498-11e3-9479-7c050710b013
I have searched the Internet (and Stackoverflow) for KERNELBASE.dll but could not find anything useful.
I have asked for help on Windows Technet without success
http://social.technet.microsoft.com/Forums/windows/en-US/ef52b2e1-237d-436f-952f-7cdecdb48337/a-problem-caused-the-program-to-stop-working-windows-will-close-the-program-and-notify-you-if-a?forum=w7itprogeneral
The program is running without the hitch on my Windows 7 x64 development machine so I cannot replicate the problem/error that I am experiencing at my client. Has anybody had a similar problem? Any suggestions for the cause/trigger of the Error and how to solve it?
UPDATE
I got the following report from madExcept but I have no idea what it means
If you include a ClientDataSet in your application you need to deploy midas.dll with your application, or you have to manually add the MidasLib unit to your project's uses clause (for example)
program Project1;
uses
MidasLib,
Forms,
Unit1 in 'Unit1.pas' {Form1};
For a detailed explanation see the article of Cary Jensen on the topic.
The screenshot from madExcept is telling you that your program is raising an exception at startup, before you call Application.Run. The root of the exception is in the call to Application.CreateForm made in your project file.
The top-level exception handler is contained in the main application message loop that is implemented in Application.Run. Because you have not yet started the main application message loop, there is no exception handler.
This means that the exception leaks out of your application and the system has to handle it as best it can.
I don't know how to fix your specific problem, but the madExcept diagnostics tell you where to start looking. Ideally you would like to be able to debug this scenario in the IDE. Once you can do that it will be much easier to track down.
Fundamentally, if you leak exceptions out of your startup code, you will encounter such error dialogs.
I know of a few things that could be potential sources of the issue. First is the space (blank) in the path name where the application is running. Trying moving app to a subdirectory with no spaces in the path name. Second try running in Admin mode if you are not already. The answer that references "midas.dll" is another one. With the additional warning that Delphi used to install a copy of midas.dll in the Windows\System32 directory. Make sure that your version of midas.dll came with the version of Delphi you wrote the code in (and make sure that there isn't another older copy being found before the one you intended. Depends.exe can help show the path to the dll it loaded. Also have you tried running the app using "XP Compatibility"? Does the issue go away? Also have problems with DB components on a DataModule form in Delphi before. If you have a DB component with a AutoConenct on (or Streamed connection), it can cause unusual errors. Best to leave it disconnected and connect it in your source code at runtime. Last thing to try, look at the Windows services and see if the Performance Logs are running prior to launching your app. A weird one, but I've seen it.
I have been battling a crash that occurs in my game engine for about 6 months now. I have recently received a few memory dumps from a tester who gets the crashes (I don't get them myself). The tester is on Windows 7 32 bit, and I am on Windows Xp 32 bit. The crashes seem to be related to Sapi, the text-to-speech part to be more exact. I am calling it via the IDispatch interface, using the wrapper found at:
http://www.morearty.com/code/dispatch/
Here are two stack traces extracted from two memory dumps.
http://www.blastbay.com/analysis1.txt
http://www.blastbay.com/analysis2.txt
The crash shown in the first stack trace occurred at random during the game's execution as it seems, and for some reason the entire stack is not resolved even though perilous_hearts.pdb is certainly present. In the second trace, it is finding the perilous_hearts symbols just fine. I am completely clueless as to what this error might be caused by. Can anyone give me some hints?
As I mentioned before, these crashes do not occur on Windows XP but only on Windows 7, both being 32 bit machines.
In both cases that crash is caused by hlas.dll, whatever that is. As the analysis says, you have heap corruption in the first stack, and a null pointer function pointer in the second. Hlas is also present in your other question about crashes in this same program.
I have a machine that periodically BSOD's. I have full memory dumps configured. Sometimes, when rebooting AFTER the BSOD, the machine sits on a black screen for several minutes, then finally comes up to windows. My colleague just recently found out that during this time, the machine was writing the full memory dump to disk.
He identified this by shutting the machine down on the BSOD, plugging the drive in as a slave, seeing that no dump file was present, plugging it back into a machine, seeing the black screen for several minutes, and then finding the memory dump on disk.
So my question is, how does this work, internally? I swear I've seen the BSOD itself telling me that it is currently writing the dump file to disk, with a counter.
What's happening is that the BSOD overwrites the pagefile with the full contents of memory in order to avoid doing any complicated processing after a critical system error (bear in mind that the cause of the BSOD could have damaged any heaps, code, unloaded drivers etc, so the BSOD basically can't rely on anything). When the system reboots it discovers that the pagefile's been marked as a BSOD, and then sets about converting the RAW dump to a minidump file that can be analysed either by Microsoft's crash-reporting server or by a driver developer analysing the crash dump in WinDbg or Visual Studio.
While I don't know for sure, its possible that it has to write RAM to disk while displaying the screen, but when it reboots, it pulls the rest of the process memory space out of the swap file to create the full core dump.
This is the first time I hear something like that. I though the dump was always writting while the BSOD is shown. You can try to connect the kernel debugger in verbose mode and figure out what's happening.
Has anyone had and solved a problem where programs would terminate without any indication of why? I encounter this problem about every 6 months and I can get it to stop by having me (the administrator) log-in then out of the machine. After this things are back to normal for the next 6 months. I've seen this on Windows XP and Windows 2000 machines.
I've looked in the Event Viewer and monitored API calls and I cannot see anything out of the ordinary.
UPDATE: On the Windows 2000 machine, Visual Basic 6 would terminate when loading a project. On the Windows XP machine, IIS stopped working until I logged in then out.
UPDATE: Restarting the machine doesn't work.
Perhaps it's not solved by you logging in, but by the user logging out. It could be a memory leak and logging out closes the process, causing windows to reclaim the memory. I assume programs indicated multiple applications, so it could be a shared dll that's causing the problem. Is there any kind of similarities in the programs? .Net, VB6, Office, and so on, or is it everything on the computer? You may be able to narrow it down to shared libraries.
During the 6 month "no error" time frame, is the system always on and logged in? If that's the case, you may suggest the user periodically reboot, perhaps once a week, in order to reclaim leaked memory, or memory claimed by hanging programs that didn't close properly.
You need to take this issue to the software developer.
The more details you provide the more likely it will be that you will get an answer: explain what exact program was 'terminating'. A termination is usually caused by an internal unhandled error, and not all programs check for them, and log them before quitting. However I think you can install Dr Watson, and it will give you at least a stack trace when a crash happens.