Re: CreateDC() problem with printer drivers on Windows Server 200x
Yogesh Rajaraman
I have just run into an issue while printing from a specific 32 bit application engine using 64 bit driver on Windows 7. I have a custom driver that tries to create a printer device context using CreateDC API from a 32-bit windows process. The CreateDC call returns NULL, but simultaneoulsy GetLastError also returns zero (not pointing to any error). I could not find anything in the system or application logs as well. Weirdly, this issue is only reproducible while printing from Adobe 32 bit PDFL Engine using our 64 bit driver. While printing from other 32 bit apps using our 64 bit driver, the issue is not reproducible. I also gave it a try on Vista x64, Windows 2008 V2 and confirmed that the behavior is consistent.
I tried disabling the UAC feature on Windows 7 but it seems to make no difference. The 32-bit process runs under an User-Account that has been granted Administrator privileges. I also tried overriding the default security settings of the process and set it to 'PROCESS_ALL_ACCESS' without any luck.
Any help will be appreciated.
> On Friday, November 28, 2008 9:31 AM Christian Kaiser wrote:
> We have a customer who gets NULL as result of CreateDC() using a
> printer driver, GetLastError() is 0.
>
> prerequisites:
> - the printer is valid,
> - it can be opened by OpenPrinter(),
> - other apps can print to that printer.
> - network printer
> - call like CreateDC("WINSPOOL", pszDriver, NULL, pDEVMODE), all
> parameters valid
>
> problem:
>
> a) how can CreateDC() return NULL and GetLastError() of 0? This is not
> according to the documentation.
>
> b) The docs for say "The function will return NULL for a DEVMODE
> structure other than the current DEVMODE." - can somebody please
> explain what that means? I do pass a valid DEVMODE (from
> DocumentProperties() of that printer), though modified (orientation
> for example). In my eyes, that sentence is nonsense (99.999% of our
> customers pass a modified DEVMODE and are quite happy). Why can I pass
> a DEVMODE to the API if it cannot be different from the default one,
> or what does that mean?
>
> Christian
>> On Saturday, November 29, 2008 2:14 PM Joseph M. Newcomer wrote:
>> I recall that in the past this problem has been cited, but I don't recall the resolution.
>>
>> It is not clear if the documentation is lying, or the CreateDC implementation is failing
>> to set the error code for some kinds of printers. But I'm going to record this as a bug
>> in my database. I will follow this thread and if any new information arises I'll add that
>> also. Unfortunately, I can't offer more advice now than trying a google search.
>>
>> Without seeing some code example, it is hard to guess; I'd suspect a bad parameter int he
>> DEVMODE structure somewhere, and a failure to properly report this, but that's pure
>> guesswork.
>>
>> joe
>>
>> On Fri, 28 Nov 2008 15:31:17 +0100, "Christian Kaiser" <bc...@gmx.de> wrote:
>>> On Monday, December 01, 2008 1:55 AM Christian Kaiser wrote:
>>> It _must_ be something wrong (I hope, as I will be able to correct it
>>> or work around it in that case) - but in 99.99% of the customers the
>>> code works. We are still researching the issue, and if we find
>>> anything, I will post it here.
>>>
>>> I still don't get the documentation issue about the DEVMODE structure.
>>> I wonder that nobody ever complained, as this is "old stuff".
>>>
>>> Christian
>>>
>>> "Joseph M. Newcomer" <newc...@flounder.com> wrote in message
>>> news:mj43j4hdl56cfp02q...@4ax.com...
>>>> On Monday, December 01, 2008 4:19 AM Christian Kaiser wrote:
>>>> Update:
>>>>
>>>> CreateDC() of the printer works when opened locally (the printer is
>>>> installed at a client computer).
>>>>
>>>> But when the customer's app runs on their Windows 2003 server, the
>>>> local printer is automatically installed on the server at login of the
>>>> remote desktop session, but the same printer cannot be used
>>>> (CreateDC() fails, GetLastError() is 0).
>>>>
>>>> Does that ring a bell with someone? I'd be glad.
>>>>
>>>> Christian
>>>>
>>>> "Christian Kaiser" <bc...@gmx.de> wrote in message
>>>> news:eVnJJH4U...@TK2MSFTNGP03.phx.gbl...
>>>>> On Monday, December 01, 2008 10:02 AM Paul Baker [MVP, Windows Desktop Experience] wrote:
>>>>> CreateDC():
>>>>> http://msdn.microsoft.com/en-us/library/ms533246.aspx
>>>>>
>>>>>
>>>>> DocumentProperties():
>>>>> http://msdn.microsoft.com/en-us/library/ms535735.aspx
>>>>>
>>>>> What OS is the client? I'm going to assume Windows XP for now.
>>>>>
>>>>> lpszDriver - You are passing "WINSPOOL", this is correct.
>>>>> lpszDevice - You are passing something called pszDriver. Make sure you are
>>>>> passing a printer name here, not a driver name or anything else. If it's a
>>>>> network printer, the name is \\server\share (preferable) or
>>>>> \\server\localname.
>>>>> lpszOutput - You are passing NULL, this is correct.
>>>>> lpInitData - You are passing pDEVMODE. This requires more discussion.
>>>>>
>>>>> (a) You ask how it can fail with GetLastError() being 0. I am pretty sure
>>>>> there is some involvement from the printer driver here. Therefore, the
>>>>> printer driver gets a chance to screw up the last error. This is probably an
>>>>> indication that the printer driver is rejecting the DEVMODE, which is
>>>>> actually rather mean of it since it could just take the standard part of the
>>>>> DEVMODE and ignore or correct what it does not understand and values that
>>>>> appear to be invalid.
>>>>>
>>>>> (b) You ask what "The function will return NULL for a DEVMODE structure
>>>>> other than the current DEVMODE" means. Wow, I have never noticed that
>>>>> before. It really makes no sense. I think what it means is that you must
>>>>> pass a DEVMODE intended for the printer driver specified. So yes, you must
>>>>> create one using DocumentProperties() for the correct printer. Try using
>>>>> that DEVMODE without fiddling with the orientation. If that's all you
>>>>> changed and it works, you know you are messing up the DEVMODE somehow and
>>>>> then you need to make sure you are following the five-step process described
>>>>> in the DocumentProperties() documentation.
>>>>>
>>>>> You say you wonder that nobody ever complained. Well, I have done plenty of
>>>>> complaining, but not always in forums in which it is productive to do so. I
>>>>> have found the design of GDI to be unforgiving to the anomolies of poorly
>>>>> written printer drivers. So be careful out there and follow the rules.
>>>>>
>>>>> I am not sure I follow exactly what you're saying about the installation of
>>>>> the printer, but In order for CreateDC() to succeed, you must have the
>>>>> correct printer driver installed locally. It may just be that the Windows
>>>>> Server 2003 server does not have the correct drivers installed for older
>>>>> OSes and the client does not have it available either. Or the client has an
>>>>> old dodgy version. It is possible that have a printer installed without a
>>>>> correct printer driver. It is also possible to use a network printer by
>>>>> specifying a UNC name even if it is not installed locally, by which I mean
>>>>> a connection via AddPrinterConnection. But it still needs the driver.
>>>>>
>>>>> Paul
>>>>>
>>>>> "Christian Kaiser" <bc...@gmx.de> wrote in message
>>>>> news:%23dmXjX5...@TK2MSFTNGP03.phx.gbl...
>>>>>> On Tuesday, December 02, 2008 2:23 AM Christian Kaiser wrote:
>>>>>> Oh, sorry, I pass the device name in the appropriate parameter, not
>>>>>> the driver's name.
>>>>>>
>>>>>> I try four different approaches:
>>>>>> driver, device, NULL, pDEVMODE
>>>>>> "WINSPOOL", device, NULL, pDEVMODE
>>>>>> driver, device, NULL, NULL
>>>>>> "WINSPOOL", device, NULL, NULL
>>>>>>
>>>>>> At least the last should work. All of them resulting in a NULL hDC and
>>>>>> GetLastError() of 0. So it cannot be the DEVMODE pointer either. The
>>>>>> device name is guaranteed to be correct (verified both by looking at
>>>>>> the log, and that OpenPrinter() succeeds).
>>>>>>
>>>>>> The device name is the one that the EnumPrinters API gives me, and
>>>>>> what the "printers and faxes" control panel shows. In case of Win2003
>>>>>> Server and a local printer, this is "HP LaserJet 1025 PCL5e (from
>>>>>> MYCOMPUTER) on session 1" or the like. Unfortunate for all
>>>>>> applications that store the printer name to be used, as the name can
>>>>>> easily change from session to session.
>>>>>>
>>>>>> It does work here this way. I tested it with a (VMWare hosted) Server
>>>>>> 2003 installation. Client is XP.
>>>>>>
>>>>>>
>>>>>> I did use NULL for testing also, see above - no success. Would have
>>>>>> been an easy solution to pass NULL and later use ResetDC().
>>>>>>
>>>>>> Thanks for telling me - the sentence did not make sense to me, but I
>>>>>> thought I might oversee something obvious ;-).
>>>>>>
>>>>>>
>>>>>> Not on Server2003 - it copies the drivers locally at login (at first
>>>>>> login, there's a myriad of "driver not digitally signed" warning
>>>>>> boxes), and then uses them. Automatically (if set in the RDP config
>>>>>> file).
>>>>>>
>>>>>> It's plain strange. Here everything works. At the customer's place it
>>>>>> does not. But when I google for Server 2003 and printers, there are
>>>>>> others having (different) problems too. So perhaps this is one amongst
>>>>>> them.
>>>>>>
>>>>>> I suggested the customer to create a share on his local computer and
>>>>>> use this at the server. Hopefully he can live with that.
>>>>>>
>>>>>> Christian
>>>>>>> On Tuesday, December 02, 2008 3:58 AM Christoph Lindemann wrote:
>>>>>>> Make sure to call "DocumentProperties" AGAIN after making any changes. This
>>>>>>> is to let the printer driver merge the settings from the public devmode part
>>>>>>> into his private devmode part:
>>>>>>>
>>>>>>> 1) Get default DEVMODE size from DocumentProperties
>>>>>>> 2) Allocate Mem
>>>>>>> 3) Get default DEVMODE from DocumentProperties
>>>>>>> --
>>>>>>> 4) Make all your devmode changes here
>>>>>>> --
>>>>>>> 5) Call DocumentProperties AGAIN with the changed DEVMODE to get a valid
>>>>>>> printer DEVMODE
>>>>>>>
>>>>>>>
>>>>>>> Btw, also ALWAYS make sure to get the device capabilities by calling
>>>>>>> "DeviceCapabilities" prior to modifying the DEVMODE. Your printer driver
>>>>>>> might not actually support your requested orientation. Do not expect the
>>>>>>> driver to support anything else then what is indicated by
>>>>>>> DeviceCapabilities. Check DC_FIELDS, DC_ORIENTATION...
>>>>>>> You might also be interested in calling "GetDeviceCaps" and "ExtEscape" to
>>>>>>> see if the current printer supports your needed bitmap operations or if you
>>>>>>> need to implement them by your self.
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Christoph Lindemann
>>>>>>> Undocumented Printing
>>>>>>> http://www.undocprint.org/
>>>>>>>
>>>>>>>
>>>>>>> "Christian Kaiser" <bc...@gmx.de> wrote in message
>>>>>>> news:epjN5XWU...@TK2MSFTNGP03.phx.gbl...
>>>>>>>> On Tuesday, December 02, 2008 9:49 AM Paul Baker [MVP, Windows Desktop Experience] wrote:
>>>>>>>> You are correct that the parameters "WINSPOOL", device, NULL, NULL avoid the
>>>>>>>> possibility that you are passing an invalidate DEVMODE.
>>>>>>>>
>>>>>>>> I wouldn't recommend passing parameters you know to be invalid just to see
>>>>>>>> what happens. Even if it works, there is a better solution and it may break
>>>>>>>> on future versions of Windows.
>>>>>>>>
>>>>>>>> It sounds like it could be related to the Terminal Services printer
>>>>>>>> redirection. If OpenPrinter() succeeds and CreateDC() fails with these
>>>>>>>> parameters, again, it would suggest a problem with the driver.
>>>>>>>>
>>>>>>>> So a Windows XP machine is using RDP to connect to a Windows Server 2003
>>>>>>>> machine and you want the Windows Server 2003 session to have access to the
>>>>>>>> Windows XP printers? That's a problem right there. You are making Windows XP
>>>>>>>> the print server, but it doesn't know about newer versions of Windows. On
>>>>>>>> the Windows XP machine, look at the driver name on the Advanced page of the
>>>>>>>> printer properties dialog. On both machines, go to the File > Server
>>>>>>>> Properties menu item to open the Print Server Properties dialog. Go to the
>>>>>>>> Drivers page. In the Name column, find all entries for the driver name you
>>>>>>>> saw. What Environments/Versions are installed? You will need to take care to
>>>>>>>> answer this for each separately.
>>>>>>>>
>>>>>>>> Paul
>>>>>>>>
>>>>>>>> "Christian Kaiser" <bc...@gmx.de> wrote in message
>>>>>>>> news:%23d5Vd7E...@TK2MSFTNGP04.phx.gbl...
>>>>>>>>> On Wednesday, December 03, 2008 5:15 AM Christian Kaiser wrote:
>>>>>>>>> I do exactly that: check the DEVMODE before calling CreateDC(). But
>>>>>>>>> apart from that, CreateDC() should work if I pass the device name,
>>>>>>>>> driver name "WINSPOOL" and no DEVMODE at all. This is what surprises
>>>>>>>>> me.
>>>>>>>>>
>>>>>>>>> As I said, usually it works (and we have thousands of customers using
>>>>>>>>> our applications and tools), it's just with that one customer, with
>>>>>>>>> his Windows 2003 server and RDP connection.
>>>>>>>>>
>>>>>>>>> Christian
>>>>>>>>>
>>>>>>>>> "Christoph Lindemann" <clind...@newsgroups.nospam> wrote in message
>>>>>>>>> news:eTZUewFV...@TK2MSFTNGP05.phx.gbl...
>>>>>>>>>> On Wednesday, December 03, 2008 5:19 AM Christian Kaiser wrote:
>>>>>>>>>> Paul,
>>>>>>>>>>
>>>>>>>>>> thank you. I will let that customer check. But the Server did install
>>>>>>>>>> the driver, so (in an ideal world) it should complain or not install
>>>>>>>>>> it if there's a conflict...
>>>>>>>>>>
>>>>>>>>>> Christian
>>>>>>>>>>
>>>>>>>>>> "Paul Baker [MVP, Windows Desktop Experience]"
>>>>>>>>>> <paulrich...@community.nospam> wrote in message
>>>>>>>>>> news:%23kRJm0I...@TK2MSFTNGP02.phx.gbl...
>>>>>>>>>>> On Thursday, December 04, 2008 1:52 PM Paul Baker [MVP, Windows Desktop Experience] wrote:
>>>>>>>>>>> Yes, I am just trying to get to the cause here, not comparing actual
>>>>>>>>>>> behaviour to desired behaviour.
>>>>>>>>>>>
>>>>>>>>>>> Paul
>>>>>>>>>>>> On Tuesday, December 16, 2008 9:55 AM Christian Kaiser wrote:
>>>>>>>>>>>> Well, now we have a second customer with a failing
>>>>>>>>>>>> CreateDC("WINSPOOL",<driver name>,NULL,NULL) returning NULL,
>>>>>>>>>>>> GetLastError() is 0.
>>>>>>>>>>>>
>>>>>>>>>>>> This time this is a Server 2008 64 bit edition (last time it was
>>>>>>>>>>>> Server 2003 32 bit).
>>>>>>>>>>>>
>>>>>>>>>>>> Facts:
>>>>>>>>>>>>
>>>>>>>>>>>> a) CreateDC() fails on all printers on that system (even an "LPT1:"
>>>>>>>>>>>> printer, but maybe it's a redirected LPT port...)
>>>>>>>>>>>>
>>>>>>>>>>>> b) "XPS document writer" is installed, but as WinSpool's
>>>>>>>>>>>> GetDefaultPrinter() returns "Microsoft XPS Document Writer (redirected
>>>>>>>>>>>> 3)" instead of "Microsoft XPS Document Writer" (which is returned by
>>>>>>>>>>>> enumerating the available printers using PRINTER_INFO_2), so it cannot
>>>>>>>>>>>> even be opened by OpenPrinter() as the device name returned by the
>>>>>>>>>>>> GetDefaultPrinter() API does not return a valid, existing device...!
>>>>>>>>>>>>
>>>>>>>>>>>> 13:21:02.470 0000192c Printers :
>>>>>>>>>>>> 13:21:02.470 0000192c : 'Microsoft
>>>>>>>>>>>> XPS Document Writer': 'Microsoft XPS Document Writer' on 'XPSPort:'
>>>>>>>>>>>> 13:21:02.470 0000192c : 'Printer_3':
>>>>>>>>>>>> 'Xerox Phaser 6180N PS' on 'nnn.nnn.nnn.nnn'
>>>>>>>>>>>> 13:21:02.470 0000192c : 'Printer_2':
>>>>>>>>>>>> 'Xerox Phaser 6180N PS' on 'nnn.nnn.nnn.nnn'
>>>>>>>>>>>> 13:21:02.470 0000192c : 'Printer_1':
>>>>>>>>>>>> 'Xerox Phaser 6180N PS' on 'nnn.nnn.nnn.nnn'
>>>>>>>>>>>> 13:21:02.470 0000192c : 'HP LaserJet
>>>>>>>>>>>> III': 'HP LaserJet III' on 'LPT1:'
>>>>>>>>>>>> 13:21:02.470 0000192c Default printer : 'Microsoft
>>>>>>>>>>>> XPS Document Writer (redirected 3)'
>>>>>>>>>>>>
>>>>>>>>>>>> The list is written using PRINTER_INFO_2, the "Default Printer" entry
>>>>>>>>>>>> using Winspool's GetDefaultPrinter() API.
>>>>>>>>>>>>
>>>>>>>>>>>> How can that be? There's obviously something wrong with Windows
>>>>>>>>>>>> Server's printer driver management...
>>>>>>>>>>>>
>>>>>>>>>>>> Christian
>>>>>>>>>>>>> On Wednesday, December 17, 2008 12:31 PM Paul Baker [MVP, Windows Desktop Experience] wrote:
>>>>>>>>>>>>> It is sounding like a printer redirection issue.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Therefore, you should try to troubleshoot it by seeing if your software
>>>>>>>>>>>>> works in all the intended scenarious for printers that are NOT redirected.
>>>>>>>>>>>>> If so, it is not a GDI issue and you can then ask your questions on a
>>>>>>>>>>>>> newsgroup that is more appropriate such as
>>>>>>>>>>>>> microsoft.public.windows.terminal_services.
>>>>>>>>>>>>>
>>>>>>>>>>>>> There may be more than one printer name that is acceptable depending on the
>>>>>>>>>>>>> context. For example, for a network printer, \\server\share or
>>>>>>>>>>>>> \\server\localname are both acceptable to WinSpool, and in addition the
>>>>>>>>>>>>> Shell can enumerate \\server\share or "share on server" and can parse "share
>>>>>>>>>>>>> on server" but this name is not acceptable to WinSpool. This is getting into
>>>>>>>>>>>>> Terminal Services again, so I don't know if your argument regarding the
>>>>>>>>>>>>> printer name is valid or not.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Paul
>>>>>>>>>>>>>
>>>>>>>>>>>>> "Christian Kaiser" <bc...@gmx.de> wrote in message
>>>>>>>>>>>>> news:uiJ1h54X...@TK2MSFTNGP05.phx.gbl...
>>>>>>>>>>>>>> On Thursday, December 18, 2008 12:12 PM Paul Baker [MVP, Windows Desktop Experience] wrote:
>>>>>>>>>>>>>> Christian,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You did not respond to this troubleshooting step:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> "So a Windows XP machine is using RDP to connect to a Windows Server 2003
>>>>>>>>>>>>>> machine and you want the Windows Server 2003 session to have access to the
>>>>>>>>>>>>>> Windows XP printers? That's a problem right there. You are making Windows XP
>>>>>>>>>>>>>> the print server, but it doesn't know about newer versions of Windows. On
>>>>>>>>>>>>>> the Windows XP machine, look at the driver name on the Advanced page of the
>>>>>>>>>>>>>> printer properties dialog. On both machines, go to the File > Server
>>>>>>>>>>>>>> Properties menu item to open the Print Server Properties dialog. Go to the
>>>>>>>>>>>>>> Drivers page. In the Name column, find all entries for the driver name you
>>>>>>>>>>>>>> saw. What Environments/Versions are installed? You will need to take care to
>>>>>>>>>>>>>> answer this for each separately."
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You said that you believed the error handling should be better if this is
>>>>>>>>>>>>>> the case. However, for troubleshooting, we need to know if this is the case.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Paul
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> "Paul Baker [MVP, Windows Desktop Experience]"
>>>>>>>>>>>>>> <paulrich...@community.nospam> wrote in message
>>>>>>>>>>>>>> news:%23jXTM1G...@TK2MSFTNGP03.phx.gbl...
>>>>>>>>>>>>>>> On Monday, January 12, 2009 11:40 AM Christian Kaiser wrote:
>>>>>>>>>>>>>>> Still waiting for the customer's answer.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But now another one also gets NULL on
>>>>>>>>>>>>>>> CreateDC("WINSPOOL","printerName",NULL,NULL), but GetLastError() is
>>>>>>>>>>>>>>> ERR_INVALID_TOKEN!.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Environment:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - Win64 server system
>>>>>>>>>>>>>>> - 32 bit AppDomain where our print engine DLL is being used by an IIS
>>>>>>>>>>>>>>> process.
>>>>>>>>>>>>>>> - impersonated user of the AppDomain has the printer (at least it can
>>>>>>>>>>>>>>> be enumerated by EnumPrinters()).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Does that ring a bell with someone?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Christian
>>>>>>>>>>>>>>>> On Monday, January 12, 2009 12:19 PM Paul Baker [MVP, Windows Desktop Experience] wrote:
>>>>>>>>>>>>>>>> Christian,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The error code returned by GetLastError may be misleading. It is more likely
>>>>>>>>>>>>>>>> to be correct if it is not Windows 95/98/Me, but the documentation for
>>>>>>>>>>>>>>>> CreateDC makes no mention that you should call GetLastError if it fails. You
>>>>>>>>>>>>>>>> have the involvement of 3rd party software that may or may not care about
>>>>>>>>>>>>>>>> such things and, as far as I know, is not mandated to care about such things
>>>>>>>>>>>>>>>> in any documentation.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So this is not new information. It is telling you CreateDC failed for an
>>>>>>>>>>>>>>>> unknown reason (the reason is never truly known with any certainty).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I have made suggestions that you did not follow up on. I cannot say much
>>>>>>>>>>>>>>>> more unless you do that.
>>>>>>>>>>>>>>>> 1. Testing with printers that are not redirected but all other factors the
>>>>>>>>>>>>>>>> same.
>>>>>>>>>>>>>>>> 2. Posting to microsoft.public.windows.terminal_services for advice on
>>>>>>>>>>>>>>>> redirected printers.
>>>>>>>>>>>>>>>> 3. Deal with questions regarding incompatible driver versions.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Paul
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> "Christian Kaiser" <bc...@gmx.de> wrote in message
>>>>>>>>>>>>>>>> news:%23izW6RN...@TK2MSFTNGP05.phx.gbl...
>>>>>>>>>>>>>>>>> On Saturday, January 24, 2009 11:30 PM Joseph M. Newcomer wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Saturday, January 24, 2009 11:56 PM Joseph M. Newcomer wrote:
>>>>>>>>>>>>>>>>>> See below...
>>>>>>>>>>>>>>>>>> On Tue, 16 Dec 2008 15:55:45 +0100, "Christian Kaiser" <bc...@gmx.de> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *****
>>>>>>>>>>>>>>>>>> No hint as to why it is failing? For example, what is the driver name (it might be an HP
>>>>>>>>>>>>>>>>>> driver, for example). Failures like this are not genernic; the might well relate to
>>>>>>>>>>>>>>>>>> Company X's driver for their hardware model P, version n.m. These are all critical
>>>>>>>>>>>>>>>>>> parameters because someone might say (as I have sometimes been able to say in the past)
>>>>>>>>>>>>>>>>>> "The version 3 driver was crap. They didn't fix it until version4, but the real fix came
>>>>>>>>>>>>>>>>>> in version 6". Been there, done that, across several different vendors and product lines.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> How much free memory do you have? Not sure this is going to be an issue, but knowning a
>>>>>>>>>>>>>>>>>> number does help sometimes. I once had a printer driver fail if you opened it in a way
>>>>>>>>>>>>>>>>>> that suggested you were going to print a full page at 600dpi; the driver needed to
>>>>>>>>>>>>>>>>>> allocate an 8.5x600x11x600=33,600,000pixels @ 24-bit color. It was a B&W printer so when
>>>>>>>>>>>>>>>>>> I set it to use 1-bit color it worked fine. Little things like this can matter.
>>>>>>>>>>>>>>>>>> *****
>>>>>>>>>>>>>>>>>> *****
>>>>>>>>>>>>>>>>>> Would I be surprised if thiz were so? Probably not. The whole point of users is to
>>>>>>>>>>>>>>>>>> develop software that tests other software by at least 102% of its design goal.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I;ve see massively confusing documentation that I believe was delivered when the designer
>>>>>>>>>>>>>>>>>> and the documentor met over lnuch and passed napkins back and forth, and never met each
>>>>>>>>>>>>>>>>>> other again. One thing I leared was the more-in-the-fringes it is, the less coherent,
>>>>>>>>>>>>>>>>>> complete, or accurate it is. That's because thousands of people insist that mainstream
>>>>>>>>>>>>>>>>>> documents be precise, but the stuff that we use once a year or three gets far less
>>>>>>>>>>>>>>>>>> attention. The further I get from mainstream, the less coherent the documentationation
>>>>>>>>>>>>>>>>>> becomes.
>>>>>>>>>>>>>>>>>> joe
>>>>>>>>>>>>>>>>>> *****
>>>>>>>>>>>>>>>>>>> On Wednesday, January 28, 2009 3:24 AM Christian Kaiser wrote:
>>>>>>>>>>>>>>>>>>> Well no, it's not easy to ask customers this, as they themselves do
>>>>>>>>>>>>>>>>>>> not have enough knowledge to answer these questions, and we don't know
>>>>>>>>>>>>>>>>>>> enough of the TerminalServer to tell them exactly what to do ;-)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> But at least for one customer, he can reproduce it easily with own
>>>>>>>>>>>>>>>>>>> CreateDC() minimal code, so we're off the hook.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Yet the fact that the device name changes is a very bad idea. I don't
>>>>>>>>>>>>>>>>>>> see that being 102% of design goal, as it's definietly unexpected
>>>>>>>>>>>>>>>>>>> behaviour of having different APIs retun different names for the same
>>>>>>>>>>>>>>>>>>> device, and not all of them work (as PrintDlg() does not seem to take
>>>>>>>>>>>>>>>>>>> into account, too, as it also fails).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Christian
>>>>>>>>>>>>>>>>>>>> On Tuesday, February 10, 2009 6:17 PM LongJoh wrote:
>>>>>>>>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Don't worry Christian; you are not going crazy! We are now seeing this too.
>>>>>>>>>>>>>>>>>>>> We have an application that has been in production for over 4 years on a
>>>>>>>>>>>>>>>>>>>> wide range of Windows OSes, with no reports of anyone ever seeing this
>>>>>>>>>>>>>>>>>>>> problem until now.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> With CreateDC(_T("WINSPOOL"),strPrinterName,NULL,NULL), we are getting a
>>>>>>>>>>>>>>>>>>>> NULL return with GetLastError()==5 (Access Denied).
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> We have isolated this problem to a 32-bit process on Windows 64 (in our case
>>>>>>>>>>>>>>>>>>>> Vista Business SP1 x64). Our process is 32-bit, so it runs under WOW. This
>>>>>>>>>>>>>>>>>>>> seems like an important clue with the same "32-bit process on a 64-bit OS" as
>>>>>>>>>>>>>>>>>>>> in your last report.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> In our case, it has nothing to do with shared printers, redirected ports or
>>>>>>>>>>>>>>>>>>>> printers, terminal services, bad drivers, Vista UAC, or any of the common
>>>>>>>>>>>>>>>>>>>> proposals we have seen here and elsewhere on the net. The call fails when
>>>>>>>>>>>>>>>>>>>> called against a local HP Laserjet 5000 on LPT1:.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I am proposing this has some relation to WOW or the thunking that must be
>>>>>>>>>>>>>>>>>>>> going on when a 32-bit process calls into the 64-bit API.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> We have not found any solution or workaround yet.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> LongJohn
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> "Christian Kaiser" wrote:
>>>>>>>>>>>>>>>>>>>>> On Tuesday, February 10, 2009 8:26 PM LongJoh wrote:
>>>>>>>>>>>>>>>>>>>>> Below are the exact steps to reproduce this problem. It seems to come into
>>>>>>>>>>>>>>>>>>>>> play when a 32-bit process, running as a user other than the interactive
>>>>>>>>>>>>>>>>>>>>> user, calls ::CreateDC() for a printer on a 64-bit OS.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> You ask why one would run a process in such a way? Simple: for process
>>>>>>>>>>>>>>>>>>>>> isolation and/or least rights security approach (like a web server add-on,
>>>>>>>>>>>>>>>>>>>>> etc).
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> (1) Build the following program as a 32-bit Windows console EXE called
>>>>>>>>>>>>>>>>>>>>> "prog.exe".
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> int main(int argc,char* argv[])
>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>> HDC hdc=::CreateDC("WINSPOOL","Printer",NULL,NULL);
>>>>>>>>>>>>>>>>>>>>> if (hdc==NULL)
>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>> printf("Error=%d\n",GetLastError());
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>> else
>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>> printf("All ok\n");
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>> return 0;
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> (2) Make a local printer named "Printer" (driver type does not matter).
>>>>>>>>>>>>>>>>>>>>> (3) Make a user (limited user, member of "Users", etc.) called "TestUser".
>>>>>>>>>>>>>>>>>>>>> (4) Execute the program as yourself from a command prompt:
>>>>>>>>>>>>>>>>>>>>> C:\> prog.exe
>>>>>>>>>>>>>>>>>>>>> (5) Execute the program again as the other user:
>>>>>>>>>>>>>>>>>>>>> C:\> runas /user:TestUser prog.exe
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Both (4) and (5) work on all 32-bit Windows that we tested.
>>>>>>>>>>>>>>>>>>>>> However, (4) works and (5) fails on Vista Business SP1 x64 (err=1008), and
>>>>>>>>>>>>>>>>>>>>> Server 2003 R3 x64 (err=0). We will try on others once we can install them.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> This is not the solution, but it should drive an MS developer directly to
>>>>>>>>>>>>>>>>>>>>> the solution.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> LongJohn
>>>>>>>>>>>>>>>>>>>>>> On Tuesday, February 10, 2009 8:32 PM LongJoh wrote:
>>>>>>>>>>>>>>>>>>>>>> Below are the exact steps to reproduce this problem. It seems to come into
>>>>>>>>>>>>>>>>>>>>>> play when a 32-bit process, running as a user other than the interactive
>>>>>>>>>>>>>>>>>>>>>> user, calls ::CreateDC() for a printer on a 64-bit OS.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> You ask why one would run a process in such a way? Simple: for process
>>>>>>>>>>>>>>>>>>>>>> isolation and/or least rights security approach (like a web server add-on,
>>>>>>>>>>>>>>>>>>>>>> etc).
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> (1) Build the following program as a 32-bit Windows console EXE called
>>>>>>>>>>>>>>>>>>>>>> "prog.exe".
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> int main(int argc,char* argv[])
>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>> HDC hdc=::CreateDC("WINSPOOL","Printer",NULL,NULL);
>>>>>>>>>>>>>>>>>>>>>> if (hdc==NULL)
>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>> printf("Error=%d\n",GetLastError());
>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>> else
>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>> printf("All ok\n");
>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>> return 0;
>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> (2) Make a local printer named "Printer" (driver type does not matter).
>>>>>>>>>>>>>>>>>>>>>> (3) Make a user (limited user, member of "Users", etc.) called "TestUser".
>>>>>>>>>>>>>>>>>>>>>> (4) Execute the program as yourself from a command prompt:
>>>>>>>>>>>>>>>>>>>>>> C:\> prog.exe
>>>>>>>>>>>>>>>>>>>>>> (5) Execute the program again as the other user:
>>>>>>>>>>>>>>>>>>>>>> C:\> runas /user:TestUser prog.exe
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Both (4) and (5) work on all 32-bit Windows that we tested.
>>>>>>>>>>>>>>>>>>>>>> However, (4) works and (5) fails on Vista Business SP1 x64 (err=1008), and
>>>>>>>>>>>>>>>>>>>>>> Server 2003 R3 x64 (err=0). We will try on others once we can install them.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> This is not the solution, but it should drive an MS developer directly to
>>>>>>>>>>>>>>>>>>>>>> the solution.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> LongJohn
>>>>>>>>>>>>>>>>>>>>>>> On Monday, March 09, 2009 7:35 PM Aaron wrote:
>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Not sure if anyone's still checking this thread, but I've tracked down somemore information.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> It appears to be related to the print Thunking Layer (splwow64.exe), which is responsible for allowing 32-bit apps to print to 64-bit print drivers.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Essentially, when a 32-bit app makes a print-related (for lack of a better description) call, splwow64.exe is launched under the calling user.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> This exe remains open for quite a while (not sure if it eventually exits or runs as a pseudo service). If a different user, non-interactive, attempts to print from a 32-bit application, it appears that they're unable to create splwow64.exe if it's already running, causing errors/application hangs.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Going off your above example:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 1) You run the app first as yourself, it launches splwow64.exe and runs successfully.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 2) Next, you run it as another, lesser user, it fails to launch splwow64.exe and CreateDC fails with 0.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> However, if you do the following (end splwow64.exe in the Task Manager, before running tests):
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 1) Run the app as another user, since splwow64 is not already running, it creates it as the lesser user, and program successfully calls CreateDC.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 2) Run the app as yourself. CreateDC will fail with 0, as splwow64 was unable to be launched under your user name.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> We ran into this issue while trying to set up a classic asp page to run under 32-bit IIS on x64 2003. Ours was further complicated by the fact that w3wp.exe, running under NETWORK SERVICE, does not seem to be able to launch splwow64 at all, resulting in RPC Server Unavailable failures.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Hopefully this information helps resolve this issue soon.