Windows Explored

I have only seen a handful of these previously and encountered another one recently, so with time permitting I decided to look at it more in-depth. The issue was that on one particular workstation, regardless of the account being used, we were unable to connect to a particular model of printer. Navigating to the printer server share, right-clicking the printer and selecting Connect resulted in the following error: “Connect to Printer. Windows cannot connect to the printer.”

The details stated that the “Operation failed with error 0x00000057.” Looking up that status code was of no help, it simply states ERROR_INVALID_PARAMETER.

The error may also present itself as: “Printer driver was not installed. operation could not be completed (error 0x00000057).”

Initial troubleshooting involved deleting the printer and going into the Print Management console and selecting the related print drivers and deleting them. This requires admin permissions and you must stop and start the spooler to unhook any drivers hooked by the spooler process. This does two things, it purges the drivers from C:\Windows\System32\DriverStore\FileRepository and cleans the registry of the printer and print driver references. In this case, this failed to correct the problem.

Some research on the Internet provided lots of similar stories and possible solutions. The first involved renaming-deleting the various .dat and INFCACHE.1 files in the root of C:\Windows\System32\DriverStore (after taking ownership); although this seems to work in most cases, I wasn’t too crazy about modifying file security permissions and deleting it as a solution*. The other involved finding the driver(s) for the specific printer in C:\Windows\System32\DriverStore\FileRepository and deleting it. The second solution seemed more practical, as the possibility existed that the driver folder may contain no drivers or only a partial list and maybe, I thought, the Print Management step taken earlier was not really deleting the drivers in the file repository. However, the file repository contains dozens of drivers and they don’t exactly lend themselves to simple naming conventions:

To obtain the name of the driver folder in the file repository, I connected to the printer myself and then navigated to the registry to obtain the path. This can be done by going to HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows x64\Drivers\Version-3\SomePrinterName. Select the printer and note the InfPath string:

With the info, I set off to find the folder on the problem workstation. However, it didn’t exist. Stumped. I turned to Process Monitor to capture a trace of the process as Explorer connects to the print server share to see if I could spot something helpful. Quickly, I spotted a log file in C:\Windows\inf\setupapi.dev.log:

I jumped to the log and opened it up and saw this:

Apparently, the OS sees that the .inf file already exist for that printer driver. A quick search for “Driver package ‘oemsetup.inf’ already exists in the Driver Store” pointed me to a Microsoft TechNet article Remove a Driver Package from the Driver Store. In short, from an elevated command prompt I ran pnputil.exe –e to confirm the oem110.inf existed:

Afterwards, I ran pnputil.exe -d Oem110.inf to remove the .inf referenced in the log and was able to successfully connect to the printer.

*My guess is that by recreating INFCACHE.1 as a possible solution, you are removing the reference to the problem oem###.inf file that the pnputil is responsible for clearing from the INFCACHE.1 file. The actual inf file is also removed from C:\Windows\inf if it exists.

If you cannot locate printer event errors in the Event System logs, under the Event Viewer expand Application and Services Logs >  Microsoft > Windows > PrintService. The details here may also shed some light on the printer driver and connectivity problems.