Error: “Can’t load SMART Utilities library (code 5) Access is denied” when printing to a Samsung Colour Laser Printer CLP-300N

System Requirements:

  • Windows 2000 Professional
  • Windows XP Home, Professional
  • Windows Server 2003
  • Windows Vista

The Problem:

When a user who is not a local/domain administrator prints to your print server you may receive the following error message on the local console account of the Print Server (Windows Server 2003).

SMART UI 32-bits Gateway error
Can’t load SMART Utilities library (code 5)
Access is denied.

SMART code 5 error message

Depending upon your situation, you may receive this error when:

  • Any user attempts to send any print job to the printer via the share
  • When a user attempts to print from Microsoft Internet Explorer and not from other applications

The error occurs using driver 1.63.11 on 2000/XP/2003 and 3.03 under Windows Vista when communicated with a printer server rather than the printer NIC directly.

If you are serving the share from 2000 or XP you shouldn’t see this issue.

More Information:

So you get a new laser printer, and the last thing that you expect is that every time someone tries to print you wind up with a support call to unblock the print queue! Yet this is exactly what Samsung seem to expect you to do.

I didn’t fiddle around when I heard about this, I checked the drivers were up to date and just logged a support call with Samsung who called back – be it 5 hours later than promised…

The support call in summary:

  1. Calls, registers
  2. Explanation of problem that printer needs unblocking every time someone sends a print job
  3. Gets put on call back queue
  4. Call back does happen, but 5 hours later than originally told
  5. Looks on expert system
  6. Expert system draws a blank
  7. Me: “Can I speak to a higher level 1 support agent?”
    Samsung: “No”
  8. Me: “Can I speak to a developer and fault report it?”
    Samsung: “No”
  9. Me: “Can you tell me when the next driver revision is due to be released?”
    Samsung: “No”
  10. Me: “Is there a new driver revision in the pipe-line?”
    Samsung: “I don’t know”
    Me: “Can you find out?”
    Samsung: “No”
  11. Me: “What are you going to do about it?”
    Samsung: “There is nothing that I can do?”
  12. The samsung guy now Google’s the problem and find exactly the same support material that I had already gone through to no avail from a user community web site Samsung guy starts reading it to me, and just to be annoying I interrupted him mid way through and continued to read the same paragraph to him from the same web page ending
    Me: “Yes I can Google too, this doesn’t work”
  13. Samsung guy now tells me to do one of the suggestions on the comments to the Google search result:
    Samsung: “If you format the server that will fix it”
    Me: “Are you out of your mind! I’m not formatting a domain controller to fix a printer problem, especially when the thing was only installed 2 months ago and there is no evidence that it would even fix the problem” (This article exists because it will not fix the problem)
    Samsung: “That is all I can suggest”
  14. Samsung guy now tells me that because there is something on Google he is sure that a developer must be aware of it and will be working on it
  15. Exasperated by this point
    Me: “OK, how about a past driver revision, perhaps if we go back to an older v1 it will sort itself out?”
    Samsung: “No, I can’t do that, I don’t have access to drivers, we can’t give them to you”
    Me: “Can you put me through to someone who can”
    Samsung: “No, there isn’t anyone”
    Me: “Can you escalate this request?”
    Samsung: “No”
  16. Me: “Can you escalate this request with a developer, supervisor or manager?”
    Samsung: “No”
  17. Me: “What do you expect us to do?”
    Samsung: “I don’t know”
  18. I summarised the situation to the monosyllabic individual on the other end of the phone
    Me: “So what you are saying is that as an organisation you find the fact that you’ve just sold us a brand new network laser printer that cannot accept a print job unless an administrator physically logs into the system console and clicks OK to an error message for each and every print job from a non-administrative user? The only advice you are willing to give me is to format an in-use domain controller to fix a printer driver problem and you find this an acceptable solution and are not willing to do anything about it?”
    … and this was the best bit:
    Samsung: “Yes”
  19. I have to say that at that point I pretty much put the phone down with a few monosyllabic intonations of my own, only realising as I did it that I didn’t tell them that they would be removed from the buying list for this.

 

The Moral of the Story

Don’t buy Samsung Printers and certainly don’t bother with their technical support in the UK.

I sincerely hope that someone in Samsung UK does read this page and does take on board the above, because quite frankly there are some serious issues in their support department.

… and yes, Samsung are no longer on any of my or my clients purchase lists.

The Fix

A couple of months went by between the support call and me actually getting around to looking at it properly – a couple of very, very aggravating months by all accounts.

In a nut shell and after some forensic analysis and some perplexing:

When your user sends off a print job to the print server, it trips off a user-level instance inside the spoolsv.exe, which determines ultimately the permissions that the user is going to have for their print job, sets up the print environment and negotiates with the driver to receive validated queue objects.

For some CONVLUTED reason, the Samsung driver is telling the spoolsv.exe process that it needs to make use of NTVDM.exe under the credentials of the user who transmitted the print job.

If you do not know, NTVDM is the NT Virtual Desktop Manager, it is the process wrapper service used to execute 16-bit (yes 16-bit) code under the 32-bit environment of Win32 (in this case).

One question: Why?
This is a printer designed exclusively for use against NT 5.0 and above (Windows 2000+), so why in blazes does it need access to a 16-bit host process to print something?!?!

This is where your having Windows Server 2003 comes into play, because there are security model changes between 2000, XP and 2003 that have caused this problem.

Windows 2000

Under Windows 2000 the default permissions for NTVDM.exe are…

  • Administrators (F)
  • Everyone (R & E)
  • Power Users (R & E)
  • SYSTEM (F)
  • Users (R & E)

Windows XP

Similarly under Windows XP…

  • Administrators (F)
  • Power Users (R & E) [Professional Only]
  • System (F)
  • Users (R & E)

Windows Server 2003

Lastly under Windows Server 2003…

  • Administrators (F)
  • Batch (R & E)
  • Interactive (R & E)
  • Service (R & E)
  • System (F)

The solution should now be self-explanatory, the user/domain user account has no access to NTVDM.exe under Windows Server 2003 by default, therefore you simply need to give the user groups Read & Execute access to the NTVDM.exe on the Widows 2003 Server that you are sharing the printer from and it will solve the access denied problem that plagues this particular driver.

This isn’t a particularly great solution as it means modifying default Microsoft file permissions, however, it will make the printer work without you having to live in front of a console session between 9am and 5pm.

… it just doesn’t explain why it needs access to NTVDM in the first place.

Cannot unhide systems files under Windows 2000, XP, 2003 or Vista

System Requirements:

  • Windows 2000, XP, 2003, Vista

The Problem:

When attempting to show hidden files in the Windows Folder Options settings window, the bivariate “So not show hidden files and folders” / “Show hidden files and folders” radio buttons do not have a pre-selected value.

Optionless Radio Buttons

No matter which of the options you chose your system will not display hidden files through Windows Explorer, and will not save the “Show hidden files and folders” setting.

More Info:

This is invariably caused by a virus infection or spyware such as (but by no means exclusive to) W32/DKR.worm.

You need to ensure that you have fully disinfected your system using AntiVirus and AntiSpyware software before making the changes to restore the functionality of the Folder Options applet. Otherwise you are frankly wasting your time by troubleshooting the problem.

 

Step 1: Why does it do it?

The virus will have modified the default property value of the registry flag responsible for specifying your preference. While Windows Explorer expects to be able to set a DWORD type for the value, the Virus will have changed the registry type to a Reg_SZ, meaning that the system is unable to read to or write to the value – hence you are unable to save your preference change after you have removed the virus from your system.

Note: If you have not removed the virus from your system then there is good reason to believe that the virus itself is preventing you from making any such that so as to prevent its own demise.

Open regedit and navigate to:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced

Incorrect (Left) : Correct (Right)

Delete the REG_SZ named Hidden, you do not need to manually recreate the DWORD. Don’t celebrate yet, follow step 2 BEFORE you succumb to the spleen bursting need that you now have to view your hidden files. Otherwise you will be doing step 1 again.

 

Step 2: Repairing the Explorer Default Flag Associations

The virus really did not want you to view hidden files on the PC, so in addition to preventing you from changing the setting, it also ensured that should you attempt to fix the problem, Explorer would simply break the setting itself – thus ensuring that there is no way that Windows Explorer is going to show you hidden files.

Navigate to:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Folder\Hidden\SHOWALL

Fix Explorer

Note the presence of the REG_SZ Checked value, this should be a DWORD value. Its job is to tell the Explorer form what to do when someone selects the Show hidden files and folders option, and currently it is being told to write a string value, not a DWORD.

Delete the CheckedValue REG_SZ, create a similarly named DWORD and set its value to equal 1 as shown in the image below.

Fixed Values

You can now view your hidden files and folders.

Error: “Drivers have NOT been updated. Compatible hardware not found. <>” when installing Hauppauge WinTV NOVA-T-500

System Requirements:

  • Windows 2000, XP, Vista
  • Hauppauge WinTV NOVA-T-500

The Problem:

It is highly possible that this error can be seen on other Hauppauge cards aside from my experience with the NOVA-T-500.

I just took delivery of what has turned out to be a rather disastrous eBuyer order, one of the products was a WinTV NOVA-T-500. If you follow the quick start guide (or even if you don’t) you may wind up being presented with the following error message:

Drivers have NOT been updated. Compatible hardware not found. <<click to exit>>

This happens if you use the CD to install from, download the latest driver package or try to use Windows Update as a means to save you from yourself.

Installer Error Screen Shot

Quite simple, Windows cannot find any driver for the application.

More Info:

My instant feeling of dread that I knew precisely what was going on aside, let me walk you through the problem; but before I do, let me give you the bad new right now – unless you have clumsily managed to half insert the NOVA into the PCTV slot, you will be in need of an RMA number because your board will not work.

 

The NOVA

On inspection the NOVA-T-500 is actually quite clever, Hauppauge have elected to keep their dual-tuner configuration as simple as possible, by sticking to what they presumably know works. The NOVA-T-500 is in effect nothing more than a PCI USB 2.0 Controller card with two USB 2.0 DVB-T tuners and a USB IR adapter connected directly to the controllers internal bus. Creative!

The NOVA-T-500

As you can see this particular NOVA-T-500 has the following model information:

  • WinTV-NOVA-T-500
  • DVB-T
  • 99101 LF
  • Rev D8B5

I actually just wanted to spell that out because I do think that is is quite a novel approach to their card design.

 

Exploring the driver install failure

A trip to device manager reveals a rather disconcerting unidentified, un-startable hardware device is present within the system – and effectively tells that Windows has no idea what to do with it

Device Manager with the NOVA-T-500

Most modern controller devices, while in their uninstalled state will usually have some sort of identifying attribute, yet here all we receive from the NOVA-T-500 is “HOOK”.

Here is the problem. All modern devices, PCI, USB, AGP – you name it – have a Plug n’ Play identifier (PnPID) which informs the operating system over who (in hexadecimal terms) manufactured the device (the Vid) and which device in their product inventory was just connected to a respective system bus (the Pid).

The WiTV NOVA-T-500’s correct PnPID is:

USB\VID_2040&PID_9951 (I believe)

While the PnPID of the device I received was identifying itself as:

USB\Vid_10b8&Pid_0066

To check your PnPID, all you need to do is visit the Details tab for the device properties in the Windows Device Manager (you can also locate it in the registry if you know where to look).

Vid & Pid PnP information

This explains why Windows was unable to locate a driver, the PnPID in the device driver cannot be matched to the one being identified by the PCI device and as a consequence, the driver installation fails.

It is possible, from time to time, to rewrite the driver ID’s (it will break WHQL certification) so that you can force Windows to mount the driver and load the hardware, I have done this several times quite successfully in the past and naturally wondered if this was going to be possible this time around.

 

Why this is not (easily) fixable

I needed to know the correct PnPID for the NOVA-T-500 and after a lightning search on the web, decided to give Hauppauge UK’s support a call. Sadly this was too technical for them, and they wanted me to phone Hauppauge support in the USA in order to out line the problem to a developer rather than to technical support. I did explain the whole EEprom PnPID issue to them, but these are effectively sales guys who have to pass everything back to HQ in the states that doesn’t come up on the expert system/knowledge base.

While I was explaining the PnPID concept to Hauppauge support, I started playing around with the driver files, and in reading through happened to notice that one of them did indeed contain the Vid/Pid combination being broadcast by my device. With finding this, I now have confirmation of what I suspected was the problem. The EEprom was blank!

; Uncomment these on production test systems to enable blank EEprom programming
;%BDA3700.DeviceDesc_cold2% = BDA3700.Device,USB\VID_10B8&PID_0066

For reference the “;” is a REM statement to comment out the information from being read by the Windows Driver loader, however the plain text comment for the section (found in hcw95all.inf, hcw95all_64.inf, hcw99bda.inf and hcw99bda_64.inf should you want to look) confirmed my suspicion. This Vid/Pid is used to program the EEprom of the device at manufacturing. My device had somehow skipped this part of its assembly, been boxed and found itself inside my computer – if it was going to happen, it was going to happen to me, of course it was!

The missing EEprom information explains why the device is identifying itself as “HOOK” to the system, with the EEprom in place, the PnPID tag would be decidedly different, without it we simply get engineering information.

This problem should be fixable by the end use so long as is a run-time reflash procedure and not a JTag style flash prcoess. If the process is JTag based then the card is not a write-off, it can simply be reflashed and sent back out again.

Either way, I have put in a support request to Hauppauge US with the information found in this article along with a request to be contacted by a developer/engineer and I shall see if they are willing to release the flash information so that I can fix it myself.

Hauppauge UK simply told me to RMA it and that they would look out for a bad batch.

 

Update – 15/01/2007

Hauppauge USA never got back to me, despite their promises to do so – shame on you Hauppauge. The replacement device from eBuyer arrived and works correctly, coming with the UK 4.0A release CD. Version 4.1 has been out for less than 24 hours at this point, so if you are a user, do go and update to the latest release.

CDO Error Message “Error ‘80040211’”

System Requirements:

  • Windows Server
  • Internet Information Services
  • ASP
  • CDO

The Problem:

When attempting to send an email using CDO under Windows Server you receive the following unspecific error message from your application debugger or web browser session:

error ‘80040211’
<path>/<file>.asp, line ##

Your application is unable to relay email into the SMTP system.

More Info:

The CDO error message is certainly due to your configuration of the SMTP server, or CDO’s inability to raise the stated SMTP server.

Step 1

A frequent cause of this error message comes from messages with lengthy message lines. It is common place within SMTP systems to refuse to transmit text lines that are greater than around 1000 characters (including the CRLF).

This does not mean that the message itself cannot be greater than 1000 characters, but that individual lines before the carriage return must be less than or equal to 998 characters (the CR [carriage return] and the LF [line feed] count as the remaining two characters).

This rule applies to plain text and to HTML messages. Ensure that your messages comply with this rule.

 

Step 2

Ensure that your ISP does not require authenticated SMTP access. If they do, you will need to modify your CDO connector to include authentication. In ASP this is achieved through the addition of the following lines into the CDO settings.

.Item(cdoSMTPAuthenticate) = cdoBasic
.Item(cdoSendUserName) = “YOUR-USER-NAME”
.Item(cdoSendPassword) = “YOUR-PASSWORD”

 

Step 3

Ensure that your system is able to connect to to the SMTP service port. A quick trick to check for SMTP connectivity without relying upon port scanners is:

  1. Open a command prompt
  2. Type:
    telnet <fully-qualified-domain-name / SMTP Server IP address> 25For example: telnet smtp.www.c-amie.co.uk 25
  3. If the path to your SMTP server is being blocked you will see the following message
    Connecting To <server>…Could not open connection to the host, on port 25 : Connect failed

If your server is unable to access the STMP network, then this error message is consistent with such a failure. The most likely cause of such a block is a firewall rule from a software firewall or a rule configured on a hardware firewall by the network administrator.

An additional consideration to make while checking for connectivity is the impact that Anti-Virus and real-time Anti-Spyware products may have. For example, McAfee Virus Scan Enterprise 8.0.0i makes use of an anti-spyware rule that prevents mass mailing worms from sending email. McAfee will block the SMTP port by default and must be configured to allow IIS (or your application) to relay email.

To reconfigure McAfee Enterprise 8.0.0i:

  1. Open Virus Scan Console
  2. Double click Access Protection
    McAfee Filters
  3. Highlight the “Prevent mass mailing worms from sending email” and click Edit
  4. For IIS 6.0 running in with standard IIS 6.0 application protection add w3wp.exe to the exceptions list.
    Exceptions List
    For application you will need to query the McAfee log file for the executable name involved in the error message. By default this log can be found at:
    C:\Documents and Settings\All Users\Application Data\Network Associates\VirusScan\AccessProtectionLog.txt