Delphi Win32 Service "Printer Selected is not valid" error on 2008 64bit standard server

Question

I have developed a simple win 32 service in delphi 7 which performs some print operations. All works fine on our XP machines, but fails on the target Windows 2008 standard server. When I put a try except block around the print statement, it results in the "Printer Selected is not valid" error.

When I check the Printer object for count of printers and event write out all the printers available in the Printer object to a file, it works fine. Only when I try to perform a print (on any printer local and network), it fails.

Based on lot of research using google, I found quite a few suggestions to use local acct, network acct, specific acct, LogonAsUser, ImpersonateUser, LoadUserProfile, etc, etc. but nothing is working. I have also set up security on the installed printers to be accessible to everyone.

This thing is really driving me crazy. Any help is greately appreciated.

Thanks

Answer 1

This is likely due to Session 0 Isolation, which was introduced in Vista. Services always run in Session 0, but in XP and earlier, the first user to log in also runs in Session 0, thus allowing services to access that user's desktop (thus allowing for "Interactive" services) and resources (like shares and printers). In Vista onwards, users never run in Session 0 anymore, so services do not have access to user-specific resources anymore. A service has to impersonate the user account it wants to access.

Answer 2

Always hard to answer an "it doesn't work" question. But I can speculate. Microsoft has warned about printing from a service in the past. I think the problem is that printer drivers are rarely designed to run in the kind of service environment that Windows 2008 provides. Services run in an isolated session, they cannot interact with the desktop anymore. Printer drivers tend to be too chatty, doing stuff like prompting the user that there's a paper jam. Or that it is time to buy a new factory approved toner cartridge. That doesn't work well in session 0, nobody can hear it scream. Quite undiagnosable, you just can't tell why the service seized-up.

Maybe they nailed this down in 2008 and blocked it completely. No idea, you'll find the people that know this at serverfault.com