I ran into an interesting problem recently. On one hand, the MS Update Catalog turns out to be a great resource for RealTek High Definition Audio driver updates. On the other hand, they come in .CAB file form. Thus, one must use a tool like 7Zip to unpack the cabinet file’s contents before updating. Then, if you point Device Manager’s update driver function at the unpacked files’ folder, it will do its thing. But not always, apparently. However, because Drive Store Explorer Shows Driver File Names explicitly, it helps target the update process more precisely. Please let me explain…
Why It Matters That Driver Store Explorer Shows Driver File Names
Normally, when you point Device Manager at a folder where new drivers are available, it identifies and applies those drivers on its own. But when I tried that a couple of versions back (18.104.22.16858) , update returned a familiar and unexpected message:
If Microsoft can’t identify the new driver, it certainly can’t install it, either.
That’s what happened to me when I clicked “Update driver,” and pointed at the unpacked cab file contents. I knew a newer driver resided somewhere in that folder. I reasoned that targeting the driver file by name might get update to install that driver, too.
That said, driver file names can be hard to run down in Windows without special help. The latest version of the Driver Store Explorer, RAPR.EXE, shows them plainly and explicitly. (Note: if you go searching for this on your own, please grab GitHub version 22.214.171.124 or newer. The older Codeplex version does not show explicit filenames.) Here’s what RAPR.exe shows me after I updated from version …8258 to the latest and greatest …8261:
RAPR told me what filename to look for in the unpacked file folder for the latest CAB file.
Using RAPR Makes Driver Filenames Explicit
When the auto-identify function failed on that previous driver update attempt, I used RAPR to get me the driver filename. Then, I targeted the file with the same name for my next update attempt in Device Manager, using the “Have Disk” option to pinpoint it exactly. Because this worked like a charm for me, I’ll suggest that should you ever find yourself in a similar situation (even if it’s not a Realtek driver) the same technique may work for you. The only gotcha I can see lurking here as a possibility is that the file of same name would no longer be the right driver file. But that possibility seems quite slim, so I merely observe it, and ask you to bear it in mind should problems present.
That’s also why prudence dictates capturing a system snapshot before you make driver changes, so you can easily roll back to your “before” state, should something go awry.