I have an application (didn't write it) that is producing APPCRASH dumps in C:\Windows\SysWOW64. The application while dumping is crippled, but operating at bare minimum capacity to not lose data. The issue is that these dumps are so large that the system is spending most of it's time writing these and the application is falling far behind in processing and will start losing data soon.
The plan is to either entirely disable it, or mount it to a RAM drive and purge them as soon as they hit the RAM drive.
Now I've looked into using this key:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb787181%28v=vs.85%29.aspx
But all it does is generate a second dump now instead of redirect the original.
The dump is named:
dump-2013_03_31-15_23_55_772.dmp
This is generally the realm of developers on Windows (with stuff like C/C++) so I'd like to hit them up, don't think ServerFault could get me any answers on this.
Additionally: It's not cycling dump files (they'll fill the 20GBs left on the hard drive), so I'm not sure if this is Windows behavior or custom code in the app (if it is... ick!).
To write a DumpFile, an app has to call the function "MiniDumpWriteDump" so this is not a behavior of the system or something you can control, it is application driven. If it dumps on crashes, it uses "SetUnhandledExceptionFilter" to set its own handling routine, before(!) the OS takes over. Unfortunately I didn't found a way to overwrite this handler from an other process, so the only hope left is, that there is a register entry for the app switching the behavior or change the path (as my applications have it for exactly the reason you describe).
Related
I want to implement a feature, that when my application crashes it saves the current data to a temporary file so it can be recovered on the next launch like many application do (eg. Word or something).
So as far as I could find out this is typically done by just saving the file every few minutes and then loading that last saved file on startup if it exists.
However I was wondering if it could also be done by catching all unhandled exceptions and then call the save method when the application crashes.
The advantage would be that I don't have to write to the disk all the time, cause SSDs don't like that, and the file would really be from the crash time and not 10 minutes old in the worst case.
I've tried this on linux with
signal(SIGSEGV, crashSave);
where crashSave() is the function that calls the save and it seems to work. However I'm not sure if this will work on Windows as well?
And is there a general reason why I should not do this (except that the saved file might be corrupted in few cases) Or what is the advantage of other applications doing timed autosave instead?
When running my asmjs\emscripten application, compiled from C++, it has suddenly started to log: "run() called, but dependencies remain, so not running" to the web console, and nothing more happens.
I've added some cout's at the absolute start of my main, but even they aren't reached.
The application executed successfully before, but suddenly this started to happen and I don't know what change triggered this.
Does anyone know how to debug this?
Update
After removing as much source code as I could, this happens as soon as I #include , even due my main simply consists of a single cout.
Ideally you would have the entire environment when it was running in version control, and build every version since to see where it broke.
You might have your code in version control, but perhaps not Emscripten itself. If you've updated Emscripten, this could lead to differences in behaviour. I would try going back to whatever version you used when it was running. Note that sometimes various cache directories survive an Emscripten version change, and might need to be cleared manually (I forgot which exactly).
The dependencies remaining could mean that you are trying to do something before Emscripten has loaded any other files it needs to, say files requested by --preload-file or --memory-init-file. Note that according to https://kripken.github.io/emscripten-site/docs/getting_started/FAQ.html#faq-when-safe-to-call-compiled-functions you should not try to run any Emscripten functions, until the C++ main function has run. To detect this, you can, for example, call your own Javascript function from main (there are other ways).
The fact this wasn't causing a problem before could have been something that seems quite unrelated: a change or update in the web browser, changing limits of concurrent downloads, or a change in the web server this is running from. You could look in the Network tab in the browser to see if anything leaps out at you as being different or suspicious.
However, as main isn't even reached, then it might not be that. I would try commenting out virtually all of your code, and make it so you have practically nothing but a hello-world program. Perhaps you don't have a correct setting in the Module object, or maybe the request for the memory initialization file is failing (you can check in the Network tab in the browser for that one). If your basic hello world program still isn't working, then you could post again, with its code, in a separate question.
This can also happens when the browser runs out of memory. Unfortunately, the browser's memory handling is not in our control so there isn't much you can do beside reducing your payload. This includes code size, preload content size, etc. Basically anything that can reduce the total memory consumption of your program will help fixing this. Browser vendors are constantly working to improve this, but it's going to take a while still.
I think you haven't given enough information to really know for sure. But it might be for instance that your js suddenly crossed some memory threshold which exceeds what the browser wants to allocate to it. You could try reducing the amount of memory used / streaming some assets instead of preloading them / ship less code / use -Os optimization level?
At the moment my info is (and let's keep the context to Windows-7, as WER doesn't work like that on Win-XP) that I have two ways of getting a full memory crash dump for my application:
I can set up WER to generate a local full memory dump of my application
The info is here: http://msdn.microsoft.com/en-us/library/bb787181%28v=vs.85%29.aspx
Add (also for 32bit apps. Do not use SysWow64 node) HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps key (possibly app specific subkey ...LocalDumps\MyApplication.exe)
Set DumpType to 2.
Tweak other settings as neccessary
Note: As our application is custom deployed, setting this registry value isn't a problem.
This seems to give me pretty reliable crash dumps with a simple demo app.
Or, I can rig up the dump writing myself - properly with watchdog process and all
I use MiniDumpWriteDump to write the dump and I do this from a watchdog process (as described here, here) to minimize risk of failure.
Question
So, which is the better approach? Given that, when doing it myself, I prudently keep the stuff I do in the crash handler to an absolute minimum, I'm wondering whether the WER approach is as reliable, or whether the WER approach does some more things in-process that
may fail. Any ideas/experiences?
As alternative to doing it yourself, you might look into Google Breakpad, wich is a library and toolset for generating and handling crashdumps.
I'm currently working on trying to resolve a crash/exception on an unmanaged C++ application.
The application crashes with some predicatibility. The program basically
process a high volume of files combined with running a bunch of queries through
the access DB.
It's definitely occuring during a file access. The error message is:
"failed reading. Network name is no longer available."
It always seems to be crashing in the same lower level file access code.
It's doing a lower level library Seek(), then a Read(). The exception occurs
during the read.
To further complicate things, we can only get the errors to occur when
we're running an disk balancing utility. The utility essentially examines file
access history and moves more frequently/recently used files to faster storage retrieval
while files that are used less frequently are moved to a slower retrieval area. I don't fully
understand the architecture of the this particular storage device,
but essentially it's got an area for "fast" retrieval and one for "archived/slower."
The issues are more easily/predicably reproducible when the utility app is started and
stopped several times. According to the disk manufacturer, we should be able to run
the utility in the background without effecting the behaviour of the client's main application.
Any suggestions how to proceed here? There are theories floating around here that it's somehow related to latency on the storage device. Is there a way to prove/disprove that? We've written a small sample app that basically goes out accesses/reads a whole mess of files on the drive. We've (so far) been unable to reproduce the issue even running with SmartPools. My thought is to try push the latency theory is to have multiple apps basically reading volumes of files from disk while running the utility application.
The memory usage and CPU usage do not look out of line in the Task Manager.
Thoughts? This is turning into a bit of a hairball.
Thanks,
JohnB
Grab your debug binaries.
Setup Application Verifier and add your application to its list.
Hopefully wait for a crash dumb.
Put that through WinDBG.
Try command: !avrf
See what you get....
Lets say I open some application or process. Did some work with that. Now I closed it.
Need to know whether this application caused any memory leak.
i.e used up some heap memory and not cleared it properly.
Can I get this statistics some how? I'm using Visual Studio (for development) under Windows OS.
Even I would be interested in knowing this information for any 3rd party application.
When an application closes all resources are automatically released by Windows.
A quick & dirty tool to get an indication for memory/resource-leaks inside an application is Perfmon.
The actions executed by an application, can cause other processes to use more memory. SQL Server can make its cache size bigger, maybe you have opened Word or Explorer, the Windows Search engine might kick in because you saved some file. The virus scanner can be more active, etc.....
Have a look at CrtSetDbgFlag:
http://msdn.microsoft.com/en-us/library/5at7yxcs(v=VS.100).aspx