[SOLVED] Same Driver Present in 95-Debug Multiple Times

blueelvis

blueelvis

BSOD Kernel Dump Senior Analyst
Joined
Apr 14, 2014
Posts
970
Location
India
I don't know whether this is a bug or not but I just analysed a couple of dump files and multiple drivers got recorded multiple times. The 95-Debug.txt file has been attached.
View attachment 10138

I have now 100+ drivers to submit to the DRT. Lot of fun work after exams :grin1:


Regards,
Pranav
 
The file (contents) should go through a "dup-elim" process to get rid of dup drivers.

I don't recall this being an issue in the past.
 
Assuming it is a new bug & until it gets fixed, you can use an app like Textpad for dup-elim.

Sort the file - cols 1-200 and check the box for "delete duplicates"

To sort the file, click on the icon that says "A-Z" with a downward arrow.

http://www.textpad.com/download/
 
Duplicates will show up if they have different date/timestamps.
I'm not 100% certain, but I think that the app parses the entire line - not just the driver name.

I see them when looking at the template.txt file - where the drivers are sorted by memory dump.
They'll repeat there if they have different timestamps (and then will duplicate in the list of links).
It helps to rule out drivers as we can tell that they've been updated.
 
usasma said:
Duplicates will show up if they have different date/timestamps.
I'm not 100% certain, but I think that the app parses the entire line - not just the driver name.
Click to expand...

IMO, John - that should not be.

I know for an absolute fact that my BSOD script's dup-elimination routine executed on driver name only.

I originally did code my scripts to perform dup-elim on driver name + timestamp, but quickly reversed that soon after the release of the then-newly updated scripts.

I was under the impression that Mike's app performed dup-elim on driver name only.

If you guys come upon a set of dumps as you describe (containing same-name drivers w/ different timestamps), please zip them up & attach to this thread so I can test and gather output files/info to pass along to Mike to help aid him in a quick fix.

I think that timestamps should have no bearing in the dup-elim process. As we have known for years now, driver timestamps in dumps are based on the user's (BSOD Analyst) time zone; hence the primary reason that we eliminated timestamp in the dup-elim process so many years ago.

All of this is (I should say "will be") a moot point when Will Watt's Admin DRT changes go in because he has addressed duplicate drivers in the TempDB (I forget now exactly how they are handled in his new code).

I am of the opinion that it is best to do *whatever* is possible to not allow dup drivers to make their way to the DRT TempDB. If you feel differently, John, not a problem with me if in fact they somehow assist you in keeping the DRT up-to-date.

usasma said:
I see them when looking at the template.txt file - where the drivers are sorted by memory dump.
They'll repeat there if they have different timestamps (and then will duplicate in the list of links).
It helps to rule out drivers as we can tell that they've been updated.
Click to expand...

I am certainly no where near as familiar with all of the features in Mike's app as you are.

What do you mean by the statement in RED.

How does having dup drivers with different timestamps help tell their update status?
 
Read More:
By checking each driver for duplicates and including any that have different timestamps, we can see in the latest .dmps whether the drivers have been updated since previous .dmps; yes, that may currently cause issues with the DRT file, but it is very helpful when debugging. I will have to do something about the DRT file duplication in the near future.

I am incredibly busy this week and weekend, but my time will free up after Tuesday afternoon. I'll try to fix many things next week, including the operating system functionality and the missing DRT files.
 
I've run it cases where the driver was updated but still out of date so you would see 2 different listing because of the dates, sometimes the driver was updated but the date is newer then in the data base and that causes a false positive too.


However I ran the last 5 dmps from that EF thread and didn't get any dups?
  • AsHIDSwitch.sys}}}
  • AsusHID.sys}}}
  • atkwmiacpi.sys}}}
  • camera.sys}}}
  • CPLMACPI.sys}}}
  • cpuz137_x32.sys}}}
  • DptfDevDisplay.sys}}}
  • DptfDevPower.sys}}}
  • dump_dumpsd.sys}}}
  • iaiogpioe.sys}}}
  • iaiogpiovirtual.sys}}}
  • iaiouart.sys}}}
  • MBI.sys}}}
  • MT9M114.sys}}}
  • panda_url_filteringd.sys}}}
  • PMIC.sys}}}
  • rtii2sac.sys}}}
  • TXEI.sys}}}
  • camera.sys}}}
  • DptfDevDisplay.sys}}}
  • DptfDevPower.sys}}}

BTW it appears to be the Asus kb driver AsusHID.sys that's acting up.....................
 
I never gave thought to "updating" referring to the OPs system, but should have!

For some reason, I thought he was referring to the DRT itself, which I simply could not get my head around - as I couldn't conceive how dups would be helpful in that case. :demb:

As I mentioned, my scripts didn't have any where near the functionality nor the customization ability that your apps do, Mike. :demb:

I only gave thought to the final 95 output & meant that it alone should go through dup-elim w/driver name & would like it to do so.

Is easier to sort the 95 txt file by the first 250 chars (est) & dup-elim looking only at the 1st 250 chars (or some other x-number of chars)? That is one method that I used.

However you think is the right methodology, there is no rush on this whatsoever, Mike.

Merry Christmas & a very Happy 2015 to you and yours, Mike!
 
I can't remember if I've seen dups in the 95 or not.
I do see dups regularly in the 98 and template files. This is mostly due to the OP updating a driver while we're troubleshooting - so I get an older driver in an older dump, then a newer one in a more recent dump.

Recently blueelvis spotted an instance of 8 NTIOLib_X64.sys drivers in one dump. They were loading from different locations due to malfunctioning MSI Control apps and had different timestamps
Here's the link: BSODs playing ANY graphically-intensive game
 
I haven't seen any duplicates till now in the 95-Debug file. It is a valid reason to have them in the 3rd party drivers.txt because it helps in determining which drivers have been updated.

It has been getting messy with the NTIOLIB and WinRing since few days. I am glad that the rest BSOD drivers are the same:grin1:
 
blueelvis said:
I don't know whether this is a bug or not but I just analysed a couple of dump files and multiple drivers got recorded multiple times. The 95-Debug.txt file has been attached.
View attachment 10138

I have now 100+ drivers to submit to the DRT. Lot of fun work after exams :grin1:


Regards,
Pranav
Click to expand...

Would it be possible to get the .dmps that caused the duplicates? I'll need something for testing next week, and since this bug is uncommon, it'll be hard to reproduce without some .dmps that cause it.
 
blueelvis said:
writhziden said:
Would it be possible to get the .dmps that caused the duplicates? I'll need something for testing next week, and since this bug is uncommon, it'll be hard to reproduce without some .dmps that cause it.
Click to expand...
Sure thing. Below are the dump files attached -
View attachment 10169
Click to expand...

I ran those 5 dumps & don't see any dups in the 95 file -
AsHIDSwitch.sys}}jcgriff2}
AsusHID.sys}}jcgriff2}
atkwmiacpi.sys}}jcgriff2}
camera.sys}}jcgriff2}
CPLMACPI.sys}}jcgriff2}
cpuz137_x32.sys}}jcgriff2}
DptfDevDisplay.sys}}jcgriff2}
DptfDevPower.sys}}jcgriff2}
dump_dumpsd.sys}}jcgriff2}
iaiogpioe.sys}}jcgriff2}
iaiogpiovirtual.sys}}jcgriff2}
iaiouart.sys}}jcgriff2}
MBI.sys}}jcgriff2}
MT9M114.sys}}jcgriff2}
panda_url_filteringd.sys}}jcgriff2}
PMIC.sys}}jcgriff2}
rtii2sac.sys}}jcgriff2}
TXEI.sys}}jcgriff2}
camera.sys}}jcgriff2}
DptfDevDisplay.sys}}jcgriff2}
DptfDevPower.sys}}jcgriff2}
dump_dumpsd.sys}}jcgriff2}
Click to expand...

@ blueelvis - please run the 5 dumps again & attach your 95 text file.
 
Mike, any update on this?

Is this resolved now in your new update EXE provided by you?
 
blueelvis said:
Mike, any update on this?

Is this resolved now in your new update EXE provided by you?
Click to expand...

Yes, this should have been fixed as of the EXE I attached for Usasma in this post. The EXE I attached for you is a further update, so both should have the fix. Let me know if you still see duplicates.
 
Hey Mike ^_^,

I got the below _95-Debug.txt when I analysed the same above dump files -
Code: 
AsHIDSwitch.sys}}blueelvis}https://www.sysnative.com/forums/bsod-processing-apps-download-%7C-information-%7C-discussions/12168-same-driver-present-in-95-debug-multiple-times.html#post89102
atkwmiacpi.sys}}blueelvis}https://www.sysnative.com/forums/bsod-processing-apps-download-%7C-information-%7C-discussions/12168-same-driver-present-in-95-debug-multiple-times.html#post89102
camera.sys}}blueelvis}https://www.sysnative.com/forums/bsod-processing-apps-download-%7C-information-%7C-discussions/12168-same-driver-present-in-95-debug-multiple-times.html#post89102
CPLMACPI.sys}}blueelvis}https://www.sysnative.com/forums/bsod-processing-apps-download-%7C-information-%7C-discussions/12168-same-driver-present-in-95-debug-multiple-times.html#post89102
cpuz137_x32.sys}}blueelvis}https://www.sysnative.com/forums/bsod-processing-apps-download-%7C-information-%7C-discussions/12168-same-driver-present-in-95-debug-multiple-times.html#post89102
DptfDevDisplay.sys}}blueelvis}https://www.sysnative.com/forums/bsod-processing-apps-download-%7C-information-%7C-discussions/12168-same-driver-present-in-95-debug-multiple-times.html#post89102
DptfDevPower.sys}}blueelvis}https://www.sysnative.com/forums/bsod-processing-apps-download-%7C-information-%7C-discussions/12168-same-driver-present-in-95-debug-multiple-times.html#post89102
dump_dumpsd.sys}}blueelvis}https://www.sysnative.com/forums/bsod-processing-apps-download-%7C-information-%7C-discussions/12168-same-driver-present-in-95-debug-multiple-times.html#post89102
iaiogpioe.sys}}blueelvis}https://www.sysnative.com/forums/bsod-processing-apps-download-%7C-information-%7C-discussions/12168-same-driver-present-in-95-debug-multiple-times.html#post89102
iaiogpiovirtual.sys}}blueelvis}https://www.sysnative.com/forums/bsod-processing-apps-download-%7C-information-%7C-discussions/12168-same-driver-present-in-95-debug-multiple-times.html#post89102
iaiouart.sys}}blueelvis}https://www.sysnative.com/forums/bsod-processing-apps-download-%7C-information-%7C-discussions/12168-same-driver-present-in-95-debug-multiple-times.html#post89102
MBI.sys}}blueelvis}https://www.sysnative.com/forums/bsod-processing-apps-download-%7C-information-%7C-discussions/12168-same-driver-present-in-95-debug-multiple-times.html#post89102
MT9M114.sys}}blueelvis}https://www.sysnative.com/forums/bsod-processing-apps-download-%7C-information-%7C-discussions/12168-same-driver-present-in-95-debug-multiple-times.html#post89102
panda_url_filteringd.sys}}blueelvis}https://www.sysnative.com/forums/bsod-processing-apps-download-%7C-information-%7C-discussions/12168-same-driver-present-in-95-debug-multiple-times.html#post89102
PMIC.sys}}blueelvis}https://www.sysnative.com/forums/bsod-processing-apps-download-%7C-information-%7C-discussions/12168-same-driver-present-in-95-debug-multiple-times.html#post89102
rtii2sac.sys}}blueelvis}https://www.sysnative.com/forums/bsod-processing-apps-download-%7C-information-%7C-discussions/12168-same-driver-present-in-95-debug-multiple-times.html#post89102
TXEI.sys}}blueelvis}https://www.sysnative.com/forums/bsod-processing-apps-download-%7C-information-%7C-discussions/12168-same-driver-present-in-95-debug-multiple-times.html#post89102

Seems like issue has been resolved. I have also submitted these drivers to the DRT now :)

Thanks a lot Mike ^_^


-Pranav
 

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

Back
Top