[SOLVED] Dumps are taking long time to load

I am not sure I completely understand the duration you've given. I do see that running the .dmps took 2037.33 seconds overall, but I cannot determine from that how much of that time was due to the kernel debugger time and how much was due to the SysnativeBSODApps loading .dmps to be run through the kernel debugger. Are you saying the SysnativeBSODApps are giving you the message that .dmps are being loaded for 2000 seconds, or it takes that long to process the .dmps from start to finish? Any way to provide a video of the behavior?


I just ran the same set in 160.567 seconds using version 10.0.15063.137 AMD64 of the debugging tools. I then ran the same set in 382.989 seconds using version 10.0.14321.1024 AMD64 of the debugging tools. Are you able to process the .dmps faster through WinDbg?
 
Are you saying the SysnativeBSODApps are giving you the message that .dmps are being loaded for 2000 seconds
Click to expand...
That's what I'm saying.

In Windbg it merely takes 5 seconds to load a single dump.


I just updated Windbg to the newest version, same results with Windbg and SysnativeBSODApp.
I'll see if I can provide a video of it.
 
I have an idea for a possible solution based on some minor changes I made in the latest update. I see you're running 2.17.1 in the files uploaded. Can you see if the problem exists with 2.17.0?


Edit: Or you could try the latest version of the app. It's nearly ready to go live, but I need to wrap up some of the help file info. It should be a bit more thread-safe than the version you're having issues with, which I think is the root of the apps being slow on your system. Some hardware may not handle some of the threading I was doing as well as other hardware.
 

Attachments

Last edited:
The latest update of the apps is now live : Sysnative BSOD Processing Apps 2.17.2. In case it's helpful to you, I found that running the apps with symbols set to [NO-PARSE]srv*c:\symbols*http://msdl.microsoft.com/download/symbols[/NO-PARSE] instead of c:\symbols radically increased the speed of the debugging tools. It used to be faster to grab the symbols locally, but that may have changed in a recent WinDbg update? You should see if that provides better behavior in your analyses.
 
The update did improve the time, but unfortunately it still takes a long time.

Due to issues in personal life I won't be able to provide a video of the behavior anytime soon.
 
Alright, I've made a video of 1 dump. I ran this dump a few times to test features of the xbox app, after the 4th time the speed was 3 times faster than the first time. It's almost like it is returning to normal run times, but I provide a video just in case.

EDIT: video removed, I didn't realize sound was recorded too (supernatural was active), will post a new reply shortly if I can't edit this post anymore
 
Last edited:
I think this may give an idea of the issue, 3 dumps and 3 extra commands (added for testing)
- !thread
- !sysinfo machineid
- !sysinfo cpuspeed


 
Okay, so it's not loading .dmps that's the issue but running them. How many instances of kd.exe are running in Task Manager? Do you see less issues if you change the number of parallel threads (Options) and/or turn parallel threading off?
 
3 instances of kd.exe.

Currently running again with parallel threads enabled and set at 20.
 
I'll let it run overnight and see how long it has taken.
 
Here's what I've done this morning.
1. Changed the symbol path to srv*g:\symbols*Symbol information instead of g:\symbols
2. Changed parallel threads to 40.
3. Disabled parallel threads and symbol path set to srv*g:\symbols*Symbol information

After the second step the app was with a single dump finally finished within 40 seconds.
With the 3rd step I noticed that parallel threads should be enabled.

As of now, it looks like enabling parallel threads and changing the symbol path has resolved this issue.
I tested the number of parallel threads too, just in case, it looks to me like it doesn't make a significant change (changed 40 to 20)
 
axe0 said:
Here's what I've done this morning.
1. Changed the symbol path to srv*g:\symbols*Symbol information instead of g:\symbols
2. Changed parallel threads to 40.
3. Disabled parallel threads and symbol path set to srv*g:\symbols*Symbol information

After the second step the app was with a single dump finally finished within 40 seconds.
With the 3rd step I noticed that parallel threads should be enabled.

As of now, it looks like enabling parallel threads and changing the symbol path has resolved this issue.
I tested the number of parallel threads too, just in case, it looks to me like it doesn't make a significant change (changed 40 to 20)
Click to expand...

The maximum number of parallel threads should be your number of processor threads x 1.5 for best results. I have an i7 system with 4 cores, but it shows up as 8 CPUs available because the i7 has hyperthreading technology. I can run with 8 x 1.5 = 12 parallel threads. If you have an i5 with 4 cores, your parallel threads would be 4 x 1.5 = 6 for the maximum. I will eliminate the guesswork for this in the next update.

As far as the symbols go, it seems like there was a change to how the symbols server is accessed by kd.exe recently. Since it seems to be affecting earlier versions of Windbg, I think it is on the server side of the symbols cache. I'll need to do more testing to verify whether it's the symbol cache and not something I changed with the app.
 
Last edited:
I'm having the same issue. + on every dump I get the message: *** ERROR: Module load completed but symbols could not be loaded for <driver.sys>.
I'd appreciated any assistance. Using latest version.
 
softwaremaniac said:
I'm having the same issue. + on every dump I get the message: *** ERROR: Module load completed but symbols could not be loaded for <driver.sys>.
I'd appreciated any assistance. Using latest version.
Click to expand...

Just checking, but did you see if the same thing happens in WinDbg?

If it does not happen in WinDbg, what symbols source are you using? Does the symbols source match the output from the apps?
 
softwaremaniac said:
WinDbg throws another error, but processes very quickly: GetContextState failed, 0x8007001E.
Local Symbols: c:\symbols (and a ticked checkbox)
Online Symbols: srv*c:\symbols*Symbol information
Click to expand...

Right, but what symbols source do you use for WinDbg? If you check the WinDbg output, does it have the same symbols source as the SysnativeBSODApps output?
 
Back
Top