The Samba-Bugzilla – Bug 2635
Unable to install printer drivers for HP InkJet CP1700
Last modified: 2005-05-30 19:50:24 UTC
I am trying to install the Windows XP printer drivers for the HP InkJet CP1700
printer on a Samba server running version 3.0.14a.
I am using the Windows XP Add Printer Driver Wizard to add the driver to the
Samba server by going to "\\samba\Printers and Faxes" in Explorer and then
opening Properties -> Advanced -> New Driver. I point the wizard to the
directory containing the unpacked driver files. The wizard copies the driver
files to the server without error messages.
After the driver has been copied to the server the wizard dialogue disappears as
normal and I am returned to the Properties window for the printer queue. When I
click Ok or Apply in this window, Explorer crashes. The following information is
shown in the resulting error window:
AppName: explorer.exe AppVer: 6.0.2900.2180 ModName: hpwantp0.dll
ModVer: 18.104.22.168 Offset: 0002f55a
When I attempt to access the printer's properties again from Explorer, I receive
the following error message and no property pages are displayed:
Function address 0x6062f55a caused a protection fault. (exception code
Some or all property page(s) may not be displayed.
I have attempted to install the same driver for a local printer queue under
Windows XP and it worked without any glitches.
Samba is installed using the pre-built RPM from the Samba.org homepage. OS is
Fedora Core 3. I have encountered the same problem on two Samba 3.0.10
installations as well as on the current 3.0.14a installation.
Client OS is Windows XP SP2 with all patches applied, including the ones from
The HP printer driver can be found at: http://h20000.www2.hp.com/bizsupport/
or by searching for drivers for "InkJet 1700" from the main HP homepage.
Jonas, try setting 'default devmode = yes' in the printer's
share definition in smb.conf. You shoudl still follow the steps
for initializing the printer however. But this might get you past
the explorer.exe crash. Some drivers are more tempermental about
NULL devicemodes than others.
no feedback from original poster. Assuming 'default devmode = yes' was
able to work around the driver problem.