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

blueelvis

BSOD Kernel Dump Senior Analyst
Joined
Apr 14, 2014
Posts
970
Location
India
Hello Sysnative ^_^,

So, I have been using the Sysnative BSOD Processing App written by writhziden for quite a long time. Yesterday, I analysed a dump file with it and analysed the same dump file with WinDBG. According to the Carrona DRT, the driver which was blamed by the WinDBG was not present in the DRT and hence I thought that the driver name would be present in the 95-Debug.txt file, but to the surprise there was no such driver mentioned.
The driver was not present even in the 3rd Party Drivers List in this case. The driver's image file which we are talking about in this case is the "vpnva64-6.sys". I have uploaded the dump file for anyone who is willing to check it with his version of the app so that the issue can be confirmed if it is only me having the problem or everyone.
https://onedrive.live.com/redir?resid=AE6D306EA85A8E10!2275&authkey=!AMpdWxrkmJ1l9yQ&ithint=file,dmp

One thing which I noticed using the WinDBG was that there were many unloaded drivers/modules like this but they were having the extension of ".sy" rather than the usual ".sys". On performing a "lmvm" followed by the driver image name did not give any results so I had to type in "lmvm vpn*" to get the module's information.

One thing which I noticed on performing an "lmtsmn" on the dump file, is that the module name and the image name were both different which is unusual since we see that the module name and image name are generally same. The module name was "vpnva64_6" whereas the image name "vpnva64-6.sys".


Any inputs are appreciated ^_^
 
The processing apps haven't been updated in a long time, and unless Mike comes back with an interest to do so, or unless someone takes over with Mike's permission and source code, it will likely stay that way provided this is in fact a bug and not an unrelated issue.

FWIW, I haven't used the processing apps in years so I can't confirm it.
 
Mike's app MAY be having an issue with the dash in the driver name; not sure.
vpnva64-6.sys
 
The app is a great aggregator and it assists the analyst in spotting patterns.
Should Mike decide to return, it'd be nice to have a centralized location where he can see what's up with the app.
And, if he doesn't come back, it may help others who are working at a better way to run the memory dumps.

FWIW - I have problems with:
- missing driver information in the 88 text file (and the older drivers listing at the top of the template file)
- freezes/lags/failure to exit (and it's hogging the hard drive when this happens)
- the missing drivers (this error seems to be more and more common recently)
- I have a concern with the app being able to handle Win10 - as I'm not familiar with how it sorts stuff.
 
The app is a great aggregator and it assists the analyst in spotting patterns.
Should Mike decide to return, it'd be nice to have a centralized location where he can see what's up with the app.
And, if he doesn't come back, it may help others who are working at a better way to run the memory dumps.

FWIW - I have problems with:
- missing driver information in the 88 text file (and the older drivers listing at the top of the template file)
- freezes/lags/failure to exit (and it's hogging the hard drive when this happens)
- the missing drivers (this error seems to be more and more common recently)
- I have a concern with the app being able to handle Win10 - as I'm not familiar with how it sorts stuff.

Umm, I am not having the issue number 2 & 3 John. Which version are you using? The latest one?

Also, is the source code for this one is with Mike only or someone else also has the access to the code?:confused2:
 
This was one of the last problems that I had reported to Mike.
Others use the same version and don't have the problems that I have.
I have tried both the latest version, and the alternate version that Mike posted - no such luck!

I expect that it's due to one of the customizations/reports that I've added.
But I haven't had the urge or the time to troubleshoot it in detail.

Mike owns the project and holds a copyright on it. He is the only one who is authorized to use the source code (I don't even know if there is a copy anyplace but on Mike's system).
 
True that.

Nice location Patrick by the way ;)
What are you called there Patrick? Root or SYSTEM?:rofl12:
 
Hello Sysnative ^_^,

So, I have been using the Sysnative BSOD Processing App written by writhziden for quite a long time. Yesterday, I analysed a dump file with it and analysed the same dump file with WinDBG. According to the Carrona DRT, the driver which was blamed by the WinDBG was not present in the DRT and hence I thought that the driver name would be present in the 95-Debug.txt file, but to the surprise there was no such driver mentioned.
The driver was not present even in the 3rd Party Drivers List in this case. The driver's image file which we are talking about in this case is the "vpnva64-6.sys". I have uploaded the dump file for anyone who is willing to check it with his version of the app so that the issue can be confirmed if it is only me having the problem or everyone.
https://onedrive.live.com/redir?resid=AE6D306EA85A8E10!2275&authkey=!AMpdWxrkmJ1l9yQ&ithint=file,dmp

One thing which I noticed using the WinDBG was that there were many unloaded drivers/modules like this but they were having the extension of ".sy" rather than the usual ".sys". On performing a "lmvm" followed by the driver image name did not give any results so I had to type in "lmvm vpn*" to get the module's information.

One thing which I noticed on performing an "lmtsmn" on the dump file, is that the module name and the image name were both different which is unusual since we see that the module name and image name are generally same. The module name was "vpnva64_6" whereas the image name "vpnva64-6.sys".


Any inputs are appreciated ^_^
I'll look into this...



EDIT: I've highlighted in Bold what is causing the apps to fail with the driver name. I had never seen them be different (or at least had never noticed it), so my apps are in uncharted territory here. I'll have to figure out a way to fix that check without breaking other driver information... What a nightmare! :thud:



EDIT2: So it turns out that check may be redundant. I'll have to do some robust checking over the next several days to make sure it does not cause the apps to crash with certain .dmp files. Anyone have a ton of .dmps I can borrow? :lol:
 
Last edited:
This was one of the last problems that I had reported to Mike.
Others use the same version and don't have the problems that I have.
I have tried both the latest version, and the alternate version that Mike posted - no such luck!

I expect that it's due to one of the customizations/reports that I've added.
But I haven't had the urge or the time to troubleshoot it in detail.

Mike owns the project and holds a copyright on it. He is the only one who is authorized to use the source code (I don't even know if there is a copy anyplace but on Mike's system).

I can help with the troubleshooting. I just need your .zdn file (Start the Apps -> Change Settings -> File -> Save As -> debug.zdn) and any .dmps you are experiencing the problems with.
 
I'll look into this...



EDIT: I've highlighted in Bold what is causing the apps to fail with the driver name. I had never seen them be different (or at least had never noticed it), so my apps are in uncharted territory here. I'll have to figure out a way to fix that check without breaking other driver information... What a nightmare! :thud:



EDIT2: So it turns out that check may be redundant. I'll have to do some robust checking over the next several days to make sure it does not cause the apps to crash with certain .dmp files. Anyone have a ton of .dmps I can borrow? :lol:

Sir, where have you been? :O
I have got tons of dump files like around 100+ but they all have been analysed :dance:. If you want them, I can upload them as well. The app is not crashing with Dump files AFAIK. It just leaves the dump files which fail to open up properly in WinDBG as well.

How is your PhD going? :thumbsup2:


-Pranav
 
I'll look into this...



EDIT: I've highlighted in Bold what is causing the apps to fail with the driver name. I had never seen them be different (or at least had never noticed it), so my apps are in uncharted territory here. I'll have to figure out a way to fix that check without breaking other driver information... What a nightmare! :thud:



EDIT2: So it turns out that check may be redundant. I'll have to do some robust checking over the next several days to make sure it does not cause the apps to crash with certain .dmp files. Anyone have a ton of .dmps I can borrow? :lol:

Sir, where have you been? :O
I have got tons of dump files like around 100+ but they all have been analysed :dance:. If you want them, I can upload them as well. The app is not crashing with Dump files AFAIK. It just leaves the dump files which fail to open up properly in WinDBG as well.

How is your PhD going? :thumbsup2:


-Pranav

I have been working on my PhD, which is going well at the moment. It has been a monumental struggle for me, but the end is in sight.

Can you upload some of the .dmps that fail to open in WinDBG and in the apps? Maybe I can find a way to circumvent the error so they do not get left behind.


As far as crashing, I am glad to hear the previous version was not crashing. However, I have made some key changes that may cause the apps to crash now. I need to do some testing over the next several days to make sure that is not the case before I release an update for everyone here to use.
 
I have been working on my PhD, which is going well at the moment. It has been a monumental struggle for me, but the end is in sight.

Can you upload some of the .dmps that fail to open in WinDBG and in the apps? Maybe I can find a way to circumvent the error so they do not get left behind.


As far as crashing, I am glad to hear the previous version was not crashing. However, I have made some key changes that may cause the apps to crash now. I need to do some testing over the next several days to make sure that is not the case before I release an update for everyone here to use.

I have deleted those dump files from my Sysnative Folder but they are still present in the Downloads Folder in ZIPPED format. I would need to extract each of them and put them to analyse so that I could send you the leftovers.
Will do it once I am back from college today afternoon.

Also, there is one problem which I have been facing and I forgot to mention it. If the app has got an access to a network connection but if the Internet Connection is not working, it will search the drivers from the corrupt DRT Reference which is downloaded and then all of the drivers and bug check codes are listed as Not found and come up in the 95-Debug.txt file. This is not resolved until and unless the app gets a working Internet Connection again. I will test the app with the Network Adapter disabled and report back the results for that as well once I am back from college.
Can a failover be implemented to revert back to a backup reference in case Internet Connection fails (It is common in India :p)


-Pranav
 
I have been working on my PhD, which is going well at the moment. It has been a monumental struggle for me, but the end is in sight.

Can you upload some of the .dmps that fail to open in WinDBG and in the apps? Maybe I can find a way to circumvent the error so they do not get left behind.


As far as crashing, I am glad to hear the previous version was not crashing. However, I have made some key changes that may cause the apps to crash now. I need to do some testing over the next several days to make sure that is not the case before I release an update for everyone here to use.

I have deleted those dump files from my Sysnative Folder but they are still present in the Downloads Folder in ZIPPED format. I would need to extract each of them and put them to analyse so that I could send you the leftovers.
Will do it once I am back from college today afternoon.

Also, there is one problem which I have been facing and I forgot to mention it. If the app has got an access to a network connection but if the Internet Connection is not working, it will search the drivers from the corrupt DRT Reference which is downloaded and then all of the drivers and bug check codes are listed as Not found and come up in the 95-Debug.txt file. This is not resolved until and unless the app gets a working Internet Connection again. I will test the app with the Network Adapter disabled and report back the results for that as well once I am back from college.
Can a failover be implemented to revert back to a backup reference in case Internet Connection fails (It is common in India :p)


-Pranav

The default behavior is to revert to a backup of the DRT. I am not sure why your system is failing to do so. I will need to do some testing on my system to see if something ran amok in a recent version.

It's been over a year since I've touched this code, so I'm a little rusty, but I'm getting back into my groove the more I work on it. :-}


EDIT: I think I see why you are getting a corrupted DRT. When prompted whether you want to use the downloaded file anyway, click No. That will allow the apps to use the backup instead of the corrupted downloaded file. If you click 'Cancel', you will start over, and if you click 'Yes', you will end up with a corrupted DRT download as you described.
 
Last edited:
The default behavior is to revert to a backup of the DRT. I am not sure why your system is failing to do so. I will need to do some testing on my system to see if something ran amok in a recent version.

It's been over a year since I've touched this code, so I'm a little rusty, but I'm getting back into my groove the more I work on it. :-}


EDIT: I think I see why you are getting a corrupted DRT. When prompted whether you want to use the downloaded file anyway, click No. That will allow the apps to use the backup instead of the corrupted downloaded file. If you click 'Cancel', you will start over, and if you click 'Yes', you will end up with a corrupted DRT download as you described.

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

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?:noidea:(Maybe 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
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top