Leftovers in the SysnativeBSODApps folder

usasma · Mar 21, 2013

On occasion I find that there is 1 dump file left in the SysnativeBSODApps folder after I run a set of dumps.
I only notice this when running a few dumps (because I can't tell if there's an extra one when I'm running many dumps).

I don't know if these are bad dumps, but I haven't received any notification of bad dump files when this happened.
I haven't tried running the leftovers, but will do so the next time it happens.

writhziden · Mar 21, 2013

0 KB .dmps will be left behind since they are ignored by the apps now. There are occasionally other .dmps left behind due to the .dmp files not being closed properly and so the apps cannot move them. It's essentially the message we get through Windows when trying to move a file or delete a file that is currently being accessed by another process on the system.

jcgriff2 · Mar 21, 2013

Can't del /f be used at the end of the run?

writhziden · Mar 21, 2013

I don't think del /f would be any different than trying to move the files. It is not that they are read only, it is that the files are being accessed by the apps at the time that they are supposed to be moved. That results in them not being able to be moved.

usasma · Mar 22, 2013

I haven't checked to see exactly what the files are - but I don't recall getting any warnings about these files either
I'll post back more the next time I find one - as it's not an everyday occurrence.

There's no problem deleting them when they happen to me.
I'm just wondering here, but would it be possible to move the delete command to later on in the process?

jcgriff2 · Mar 22, 2013

writhziden said:
I don't think del /f would be any different than trying to move the files. It is not that they are read only, it is that the files are being accessed by the apps at the time that they are supposed to be moved. That results in them not being able to be moved.

Is it just the app using the dump or is it a case of another app using it, like when I sometimes have a dump(s) open in Windbg while the app is running? In the latter case, I know that particular dump(s) will not be deleted/moved.

usasma said:
I'm just wondering here, but would it be possible to move the delete command to later on in the process?

My thoughts as well.

I thought there was a DEL command at EOJ - like a housekeeping routine.

So ... the dumps are MOVEd after each is processed v. one step at EOJ?

writhziden · Mar 22, 2013

The very last step in the apps is a cleaning process to move all analyzed .dmps to the output folder and all .dmps that were removed from analysis are moved to the %TEMP%\SysnativeBSODApps\<RandomNumber> directory. For some unknown reason, even though I tell the apps to close a .dmp as soon as it is done with it, it does not always successfully do so. I will re-check my close statements to make sure I did not miss one, but I am fairly sure I have not.

I don't think this is a case of having a file open in WinDbg since I do not do that on my machine, and I have also encountered the lone straggler at times. I'm sure having one open in WinDbg and the apps would prevent the cleanup, though, so that would explain the occurrence in some situations. :-}

Also, for 0 KB sized .dmps, I do not have any error messages that appear anymore. If the .dmps that are left behind are 0 KB, that would also explain why they are not being moved during the cleaning process.

jcgriff2 · Mar 22, 2013

Just curious Mike --

Why would del *.dmp /q not delete 0 byte .dmp files?

writhziden · Mar 22, 2013

It doesn't?

I think I've narrowed down why some non-zero .dmps are being left behind. During the .dmp check to see if a file has the hex heading for the .dmps, I forgot to close the .dmps afterward. It's surprising any of the .dmps were being moved... :confused2:

To make things a little clearer as to how the apps currently behave:

Check files in the folder to see if they contain the hex heading for .dmps
If files do not contain the header, ignore the file as a possible candidate for analysis and do not add it to the list of .dmps
Let the user decide which of the possible candidates to run the debugging tools on
Those that are chosen are analyzed, parsed for summary, and then during the clean up phase are moved to the output folder inside a dmps directory
Those that are not chosen are not analyzed and then during the clean up phase are moved into the %TEMP%\SysnativeBSODApps\<RandomNumber>\oldDmps directory.
Any files that were not candidates, including 0 KB .dmp files, are left in the folder where analysis took place, e.g. %userProfile%\SysnativeBSODApps\*.dmp for those who run out of the installation directory.

Would it be better to have all 0 KB files deleted from the system when files are checked? This can be done, and an error message will appear in the progress window where error messages are written.

jcgriff2 · Mar 22, 2013

Before I begin (zip extraction/copy to 2nd panel w/Altap), I sort \SysnativeBSODApps dir by EXT, quickly check for DMP files; if any found, I delete them.

I myself prefer no DMP files to exist in \SysnativeBSODApps dir before starting a new run.

I've been burned a few times (running prior DMPs w/ current) -- MY FAULT, not your app's fault b/c of my use of Windbg on occasion.

writhziden · Mar 22, 2013

At least the 0 KB .dmps are ignored, so if they do remain, they don't affect subsequent runs. For a cleaner scenario, I think I will just go ahead and delete any 0 KB dmp or txt files; empty files are pointless in most situations anyway.

I've made a few other rather minor changes to the apps over the past few weeks. I'll be releasing an update over the weekend with a few minor bugfixes and safer parallel threading I've learned from work.

Tekno Venus · Mar 22, 2013

jcgriff2 said:
Before I begin (zip extraction/copy to 2nd panel w/Altap), I sort \SysnativeBSODApps dir by EXT, quickly check for DMP files; if any found, I delete them.

I myself prefer no DMP files to exist in \SysnativeBSODApps dir before starting a new run.

I've been burned a few times (running prior DMPs w/ current) -- MY FAULT, not your app's fault b/c of my use of Windbg on occasion.

I've never had an issue with this, although I don't do anywhere near as much analysis as you, so probably never cam across it.

All my BSOD dumps are in separate folders for each forum and then folders by username. I can find any users output by searching their usename. BSOD app copied to their folder and run on their dumps :)

Search

Search

Leftovers in the SysnativeBSODApps folder

usasma

Retired Admin

writhziden

Administrator, .NET/UWP Developer

jcgriff2

Co-Founder / Admin
BSOD Instructor/Expert
Microsoft MVP (Ret.)

writhziden

Administrator, .NET/UWP Developer

usasma

Retired Admin

jcgriff2

Co-Founder / Admin
BSOD Instructor/Expert
Microsoft MVP (Ret.)

writhziden

Administrator, .NET/UWP Developer

jcgriff2

Co-Founder / Admin
BSOD Instructor/Expert
Microsoft MVP (Ret.)

writhziden

Administrator, .NET/UWP Developer

jcgriff2

Co-Founder / Admin
BSOD Instructor/Expert
Microsoft MVP (Ret.)

writhziden

Administrator, .NET/UWP Developer

Tekno Venus

Senior Administrator, Developer

Leftovers in the SysnativeBSODApps folder

Retired Admin

Administrator, .NET/UWP Developer

Co-Founder / AdminBSOD Instructor/ExpertMicrosoft MVP (Ret.)

Administrator, .NET/UWP Developer

Retired Admin

Co-Founder / AdminBSOD Instructor/ExpertMicrosoft MVP (Ret.)

Administrator, .NET/UWP Developer

Co-Founder / AdminBSOD Instructor/ExpertMicrosoft MVP (Ret.)

Administrator, .NET/UWP Developer

Co-Founder / AdminBSOD Instructor/ExpertMicrosoft MVP (Ret.)

Administrator, .NET/UWP Developer

Senior Administrator, Developer

Co-Founder / Admin
BSOD Instructor/Expert
Microsoft MVP (Ret.)

Co-Founder / Admin
BSOD Instructor/Expert
Microsoft MVP (Ret.)

Co-Founder / Admin
BSOD Instructor/Expert
Microsoft MVP (Ret.)

Co-Founder / Admin
BSOD Instructor/Expert
Microsoft MVP (Ret.)