Driver Not Showing Up in 95-Debug.txt/3rdpartydriver File

[writhziden]

I found two dump files which were corrupt in my recent analysis. I have attached them below -
View attachment 9783

WinDBG is spitting up Parameter is incorrect. The dump files are not visible at all in BlueScreenView. These dump files (which are corrupt) should be deleted IMO. I wonder what causes such corruptions?:noideaMaybe Disk Driver not being able to save the Dump file properly? )

I tried the method suggested by you and it worked correctly. I think the dialog box needs to be edited to suggest the proper information with the "NO" Option as well.

Also, I have seen the "Update Available" popping up many times during my normal use of the system even when the App was closed. I tried finding the app in the currently running processes and services but I was not able to find any. Nor I was able to find any Task Scheduler Entries for the app. I have noticed that this window pops up regularly for like around 10 days and then not for a month and then repeats again. The period of the window is vague but it has a similar pattern.

Thanks Mike!:rose:
-Pranav

Alright, nothing I can do about the defective .dmps since I would be hesitant to leave that decision to the apps. They are missing the header information, which is why they fail to load with the apps and probably why they fail to load in WinDBG. I could delete any .dmp files left over in the end, but I do not think that would be a responsible way to handle it in case users had saved .dmps that they did not want analyzed, added .dmps after processing started, etc.

As to the error message with the DRT download, I have made the following change:




I am not sure why you are receiving the update notification even when the apps are not running. I have not experienced that on any of my test systems. Is anyone else experiencing the same behavior?

 

[blueelvis]

That Error code is sure fancy:lol:

Line 4 should be = "Press Cancel To Restart The App" . Remove the (s).

IMO Line 5 should be removed completely and have Line 6 & 7 only after Line 4.


Regarding the defective dump files, I managed to get the following log file from the defective dump file -

Opened log file 'log.txt'
Microsoft (R) Windows Debugger Version 6.3.9600.17237 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x64\Dump.dmp]
Could not match Dump File signature - invalid file format
Could not open dump file [Dump.dmp], Win32 error 0n87
    "The parameter is incorrect."

Can't this be checked? It can be checked I think but I also think that this will add unnecessary overhead and coding all this part won't be easy and short. The benefit of this would not be much IMO.


Also, is it possible to limit the number of worker threads spawned by the App? I opened around 19 Dump files with this app today (It was not a Test Case but a real case), it spawned that many threads of the Kernel Debugger utilizing my CPU 100% and freezing the system every 10-15 seconds (My laptop has got i5).

Regarding the updates, it is random sometimes. Sometimes it will popup every time I run the app and sometimes it will lie dormant for few days.

Thanks!


-Pranav

 

[writhziden]

That Error code is sure fancy:lol:

Line 4 should be = "Press Cancel To Restart The App" . Remove the (s).

IMO Line 5 should be removed completely and have Line 6 & 7 only after Line 4.

How's this?

Can't this be checked? It can be checked I think but I also think that this will add unnecessary overhead and coding all this part won't be easy and short. The benefit of this would not be much IMO.

It is already checked, but if the header is missing, the apps disregard it as a .dmp to analyze. I'll put some more thought into it and how I want to handle it. I just would not want to hard delete a file that has a .dmp extension by mistake or something similar.

Also, is it possible to limit the number of worker threads spawned by the App? I opened around 19 Dump files with this app today (It was not a Test Case but a real case), it spawned that many threads of the Kernel Debugger utilizing my CPU 100% and freezing the system every 10-15 seconds (My laptop has got i5).

Regarding the updates, it is random sometimes. Sometimes it will popup every time I run the app and sometimes it will lie dormant for few days.

Thanks!


-Pranav

It is entirely possible to turn off or change the multi-threading capability:

1. Open the apps (yes, apps, not app; there is history behind why SysnativeBSODApps is plural and not singular)
2. Click on Options
3. Uncheck Use Parallel Threading or you can also ChangeNumberThreads

 

[blueelvis]

How's this?

Perfect ^_^

It is already checked, but if the header is missing, the apps disregard it as a .dmp to analyze. I'll put some more thought into it and how I want to handle it. I just would not want to hard delete a file that has a .dmp extension by mistake or something similar.

Yup. Or you can have the app delete the dump files missing the Header Information?

It is entirely possible to turn off or change the multi-threading capability:

1. Open the apps (yes, apps, not app; there is history behind why SysnativeBSODApps is plural and not singular)
2. Click on Options
3. Uncheck Use Parallel Threading or you can also ChangeNumberThreads

Thanks for that. I reduced mine to 10. Default was set to 20. I wonder why the plural in this case :huh:


Thanks Mike!
-Pranav

 

[writhziden]

Yup. Or you can have the app delete the dump files missing the Header Information?

Yes, but which .dmps, .hdmps, .mdmps, .DMPs, .txts, etc. does it delete? There are multiple extensions, and people sometimes change their extensions to .dump or .txt, making it more difficult to determine which are missing the header and which are files the analysts have in their directories.

The apps have to work for everyone, so what might work for you might cause conflicts for someone else. I know at least two people who use the apps and have their .dmp files mixed in with tons of other important files. I need to avoid hasty decisions that might greatly impact those users.

I wonder why the plural in this case :huh:


Thanks Mike!
-Pranav

You're welcome. And below, I have the story behind why the apps are plural instead of singular:

Going back to the jcgriff2 app, the original scripts were developed by John Griffith (jcgriff2), and those scripts ran through .bat and .VBS scripts. Those were designed to obtain relevant information from the kernel debugger analyses. The relevant info chosen included that which John used in his blue screen analyses with the forums he worked in. Richard (niemiro), at John's behest, ported those scripts into a C++ application with the intent that they be available to all analysts. He began and did much of the important development so users had options for the output. Those were developed and used by many here up to version 1.2.0.0.

As some know, I was developing my own app with similar designs. I started the app more as a hobby, and then it became a necessity due to restrictions placed on the ability to obtain the app here on the forums I was initially working on to help users with BSODs. My app grew due to the necessity to train others in BSOD analysis. Eventually, I left those forums and joined here. Some were still using my app here, but from my perspective, it was nowhere near as effective as what John and Richard had accomplished here. There were some features that were different that people liked, though, so I spent a weekend rebuilding it to make it faster, more efficient, and to incorporate more options into it. I went as far as to say the redesign was version 2.0 of my own app (although, it probably still was closer to version 1.0 of the jcgriff2 app).

Due to the features people liked in my app and the features that people liked in the jcgriff2 app, John, Richard, and I discussed a merging of the two apps and called them the Sysnative BSOD Apps [The merging of the apps is what led to the plural].

 

[blueelvis]

You are right Mike. Take your time to think through this, I will let you know in case I am able to come up with an idea as well :)


So that's the story behind the "s".


Thanks Mike for your work!

-Pranav

 

[blueelvis]

Mike, I just analysed a couple of dump files from a list (several) dump files using the Apps and the dump files which were not marked for analysing by the Apps have vanished from the folder. Those are not even in the Output/Dmps folder.

Any idea what might have happened?

-Pranav

 

[writhziden]

Mike, I just analysed a couple of dump files from a list (several) dump files using the Apps and the dump files which were not marked for analysing by the Apps have vanished from the folder. Those are not even in the Output/Dmps folder.

Any idea what might have happened?

-Pranav

Any chance they were size 0 kb files?

 

[blueelvis]

Mike, I just analysed a couple of dump files from a list (several) dump files using the Apps and the dump files which were not marked for analysing by the Apps have vanished from the folder. Those are not even in the Output/Dmps folder.

Any idea what might have happened?

-Pranav

Any chance they were size 0 kb files?

Nope, the dump files had a size and were opening properly on opening them with WinDBG/BlueScreenView

 

[writhziden]

Nope, the dump files had a size and were opening properly on opening them with WinDBG/BlueScreenView

That's odd. Can you upload them here? The apps are only supposed to delete files that have no size to them. If they're deleting good files, that's a bug that needs fixing ASAP.

 

[blueelvis]

Below is the attached ZIP File for dumps. I cross checked my findings and yes I was able to reproduce the bug. I just selected a random of the whole bunch. The apps analysed it and only one dump was in the Dmps folder and the rest just disappeared.
I guess this is the kind of bug you were talking in your previous posts. Glad that it is found :)
View attachment DMPs.zip


-Pranav

 

[writhziden]

Below is the attached ZIP File for dumps. I cross checked my findings and yes I was able to reproduce the bug. I just selected a random of the whole bunch. The apps analysed it and only one dump was in the Dmps folder and the rest just disappeared.
I guess this is the kind of bug you were talking in your previous posts. Glad that it is found :)
View attachment 9895

-Pranav

Are you talking about analyzing only one .dmp out of a batch by selecting it from the following list?



Any .dmps that were not selected get moved to %TEMP%\SysnativeBSODApps\{randomNumber}\oldDmps

They are preserved, but since you did not analyze them, they are stored as temporary files. The intention is not to clutter the output directory with .dmps that are not of interest. If you want to analyze others, you would need to download them again or store them in another location.

 

[jcgriff2]

Any .dmps that were not selected get moved to %TEMP%\SysnativeBSODApps\{randomNumber}\oldDmps

They are preserved, but since you did not analyze them, they are stored as temporary files. The intention is not to clutter the output directory with .dmps that are not of interest.

That makes sense to me as I would expect the output reports to reflect only those dumps processed; therefore I would expect only those dumps processed to be saved.

My old batch/VBS scripts worked basically the same way (only saved the dumps actually processed). There was no list to select from; the scripts processed only those dumps copied/extracted into the active sub-directory.

 

[usasma]

Just rereading through this topic and noticed that blueelvis had the freezing issue that I had.
In my case it turned out to be due to my hard drive.

The system came with a 5400 rpm SATA drive and I was having real problems when running multiple memory dumps
I first upgraded the RAM from 8 gB to 12 gB - yet the problems continued
The 2 biggest symptoms that I had were:
- "freezing" of the system (if left long enough, it would eventually unfreeze)
- the app wouldn't close after it was done, leaving multiple instances in Task Manager (this caused even more freezing, so I resorted to manually ending the process' after I finished running the app)
I upgraded my system to an SSD and I haven't had a problem since!

 

[writhziden]

Just rereading through this topic and noticed that blueelvis had the freezing issue that I had.
In my case it turned out to be due to my hard drive.

The system came with a 5400 rpm SATA drive and I was having real problems when running multiple memory dumps
I first upgraded the RAM from 8 gB to 12 gB - yet the problems continued
The 2 biggest symptoms that I had were:
- "freezing" of the system (if left long enough, it would eventually unfreeze)
- the app wouldn't close after it was done, leaving multiple instances in Task Manager (this caused even more freezing, so I resorted to manually ending the process' after I finished running the app)
I upgraded my system to an SSD and I haven't had a problem since!

That is very interesting. I was under the impression it was an overload of the processor that slowed things down, but given that hard drives are the bottleneck in systems, your findings make sense. That possibility never occurred to me, though. Thanks!