Skip to main content

 none
On Vista x64, DocumentProperties fails from UAC-elevated process RRS feed

  • Question

  • Hi,

     

    I'm using Vista x64 and debugging a 32-bit program in Visual Studio 2008. I've found something that you are allowed to do if you're not an administrator, but you are not allowed to do if you are an administrator!

     

    If I call OpenPrinter to get a handle to any local printer, and then call DocumentProperties with the handle and the printer name (but every other parameter NULL or zero) to discover the size of the DEVMODE for that printer, it fails if the process is running in "elevated" mode. Of course, I'm most often running in this mode because I'm debugging within Visual Studio 2008, which warns me to always run the IDE elevated to administrator.

     

    In the call to OpenPrinter, it makes no difference whether I use PRINTER_ACCESS_ADMINISTER or PRINTER_ACCESS_USE as the access mask.

     

    When I call GetLastError/FormatMessage to discover a description for what has failed, FormatMessage doesn't return anything, which suggests this is a bug rather than a deliberate security decision.

     

    Obviously XP has no problem here. Also, x86 (32-bit) Vista always succeeds, regardless of whether the process is running elevated or not. But x64 Vista is only okay unless I run my program elevated (either for the purposes of debugging, or if I manually start it by right-clicking and choosing Run as administrator).

     

    Not surprisingly, this is causing serious problems debugging my program! Until it's resolved, Vista on x64 isn't a useful development environment.

     

    Has anyone else hit this? Is this a known issue, or is there a workaround or setting I can change to fix it?

     

    Thanks!

     

    Monday, January 14, 2008 9:54 AM

All replies

  • This sounds like it may be related: In Vista x64, if you run any Microsoft office 2007 program in elevated mode (for example MS Access, by right-clicking on msaccess.exe in the ms office program directory and selecting run as administrator), and try to print, it will say "no printers are installed."  Running it unelevated, you can print, but then you run into problems in certain situations from the lack of privileges, esp when trying to run certain vba code.  The behavior of much vba is also broken if you are communicating between unelevated and elevated programs (for instance using unelevated ms access to call elevated excel--getobject returns a read-only locked spreadsheet, and there are other, peculiar automation crashes). 

     

    The workaround, at least with regard to the "disappearing" printers, is to use NET USE, according to Mark Russinovich:

    The issue stems from the fact that the unelevated and elevated processes actually run in different logon sessions. Network connections, including printers, are configured per-session. The workaround is to run an elevated command prompt and establish connections to the printer via "net use."

     

     

    Hi,

     

    I'm using Vista x64 and debugging a 32-bit program in Visual Studio 2008. I've found something that you are allowed to do if you're not an administrator, but you are not allowed to do if you are an administrator!

     

    If I call OpenPrinter to get a handle to any local printer, and then call DocumentProperties with the handle and the printer name (but every other parameter NULL or zero) to discover the size of the DEVMODE for that printer, it fails if the process is running in "elevated" mode. Of course, I'm most often running in this mode because I'm debugging within Visual Studio 2008, which warns me to always run the IDE elevated to administrator.

     

    In the call to OpenPrinter, it makes no difference whether I use PRINTER_ACCESS_ADMINISTER or PRINTER_ACCESS_USE as the access mask.

     

    When I call GetLastError/FormatMessage to discover a description for what has failed, FormatMessage doesn't return anything, which suggests this is a bug rather than a deliberate security decision.

     

    Obviously XP has no problem here. Also, x86 (32-bit) Vista always succeeds, regardless of whether the process is running elevated or not. But x64 Vista is only okay unless I run my program elevated (either for the purposes of debugging, or if I manually start it by right-clicking and choosing Run as administrator).

     

    Not surprisingly, this is causing serious problems debugging my program! Until it's resolved, Vista on x64 isn't a useful development environment.

     

    Has anyone else hit this? Is this a known issue, or is there a workaround or setting I can change to fix it?

     

    Thanks!

     

    Monday, June 16, 2008 7:28 AM
  • We are convinced that VISTA64 (or WOW64 virtual environment for 32 bit applications) has a bug which causes 32 bit applications on certain computers to fail to print.
    This post was initially posted on Intuit's forum topic regarding printing problem with Intuit applications on VISTA64.

    The difficulty is convincing Microsoft that there is a problem with their system. In general, for previous reports of the problem, Microsoft cannot reproduce the problem, so the case is 'closed', and the suffering software application trying to print is blamed. The problem only appears on some computers. From a programmer's perspective, it appears to be an 'initialization' situation, ie. the memory where some data variable/s happen to be stored, on a particular computer, may or may not have default value/s that are favorable or unfavorable to a function call's result. As programmers, we are taught to initialize all data to some known value, usually 0. So if the data happens to be assigned memory that happens to have a proper initialized value, the problem does not appear. On another computer, the data may be assigned to memory with some random value, which may cause the function to return 'failure'.

    In this case, we traced the call to DocumentProperties() which is used to retrieve properties of a selected printer. There are two calls. The first call is a simple request for the size of the DEVMODE structure that the printer driver will need to fill with that printer's properties. The application uses the size to allocate memory for the properties which are filled in by a second call to DocumentProperties().

    It is the first call that fails, no matter which printer is selected. It is a very simple request, and one 32 bit integer value should be returned in the range of 500 to 5000 or so. A -1 is returned, when the bug manifests itself. A call to 'GetLastError()' does not indicate any error.

    Microsoft also provides a 'PrintDlg()' method in a comdlg32.dll which provides a convenient 'wrapper' for the 'OpenPrinter()' and 'DocumentProperties()' and other printer management functions. Using PrintDlg(), the error returned from CommDlgExtendedError() is CDERR_MEMLOCKFAILURE 0x0000000a which seems to indicate that a 'lock' on allocated memory of -1 size (-1 is also 0xffffffff a very large number) is failing.

    These are hints for the Microsoft programmers to check. I don't see a whole lot of code to check. The size of DEVMODE request would seem to be a straight 'pass through' to the printer driver identified by the 'handle' received from previous 'OpenPrinter()' call. Since all printers fail, when the bug manifests itself, then the software code 'to' and 'back' from the printer driver call needs to be reviewed.
    Tuesday, November 18, 2008 10:29 AM
  • Does it help to set the 3rd parameter of your OpenPrinter call to NULL?
    Thursday, November 20, 2008 5:09 PM
  • I agree that there's a problem.  I have a standard PrintDlg call that has been working flawlessly for years, that is now causing problems on some Vista Ultimate computers, actually crashing the process.

    After much research on the web, I found that passing in a NULL hWnd (rather than the real parent) masks the problem.
    Thursday, November 20, 2008 5:55 PM
  • The call to OpenPrinter() returns a printer 'handle' value, and I would presume it is ok.  It is the next rather uncomplicated call to DocumentProperties that fails in 64bit VISTA for some applications on some computers.  We have also confirmed that lowering execution 'elevation' down from 'administator', the 'bug'  'goes away'.  This is clearly a Windows issue and not application program trying to print.  To remind everyone, when the 'bug' appears, it affects all printers on that computer - LaserJet, Canon InkJet, CutePDF virtual printer, Microsoft FAX, and Word XPS Document Writer in my case.

       //
       // 12 Nov 2008
       // Call windows API.
       //
       int nResult = :: OpenPrinter(
          pPrinter,  // LPTSTR printer name 0 terminated string - NOT unicode.
          &hPrinter, // LPHANDLE returned - looks ok
          NULL       // LPRINTER_DEFAULTS
       );
      .
      .
       //
       // A zero for last param fMode returns the size of buffer needed for the
       // information to be returned.
       //
        long lSizeDevMode = :: DocumentProperties(
          NULL,    // HWND hWndParent
          hPrinter, // handle to printer object
          pPrinter, // LPCTSTR printer name
          NULL,   // PDEVMODE output
          NULL,   // PDEVMODE input
          0       // DWORD fMode
       );
        ASSERT(lSizeDevMode >= 0);


    Thursday, November 20, 2008 6:33 PM
  • I use similar calls, except for not having a NULL window handle on the DocumentProperties call. I have seen the entire printer list disappear occasionally after re-connecting locally to a session that had been connected to via remote desktop. When this happens, are your printers available to other apps and do they still appear in the list of printers in Start | Settings | Printers?
    Thursday, November 20, 2008 8:01 PM

  • The application code uses the Windows API ::EnumPrinters(..) to build a list of printers for the application user to select the printer to use for printing. This always succeeds.  The text string for 'printer name' selected from that list is passed to OpenPrinter(..) which returns a 'handle' to the selected printer.  It is the next call to DocumentProperties(..) requesting the size of the DEVMODE record for the selected printer that fails.  And it fails regardless of the printer selected from the list obtained from Windows via ::EnumPrinters(..). 

    The alternative more convenient call to Windows PrintDlg(..) - which encapulates all  the methods mentioned plus others including a nice printer selection dialog, fails before the dialog appears.  And returns the error mentioned in previous posts.
    CommDlgExtendedError() returns CDERR_MEMLOCKFAILURE 0x0000000a.  This implies that DocumentProperties(..) is failing in PrintDlg(), but PrintDlg() is trying to 'GlobalLock()' the -1 (0xffffffff) returned by DocumentProperties() in anticipation of the next call to DocumentProperties(). to get the DEVMODE record filled with the printer's properties.

    I currently don't have direct access to laptop that demonstrates the bug.  I have asked my associate, who owns the laptop, regarding any problems with the printer list in the 'control panel'.  There has been no mention of any such problem.


    Thursday, November 20, 2008 9:22 PM
  • Sorry, I've never had the exact failure you describe. Anytime I've had a problem with printers, they have always simply been mising from the list of printers, which a simple logoff, logon fixed.

     

    I do use both EnumPrinters (for a more secure environment where group policy restricts the use of PrintDlg) and PrintDlg and have both 32bit and 64 bit Unicode versions of my app. In the comments of your sample code you reference Unicode? Are you seeing some Unicode vs. ANSI issues with the printer name?

     

    Thursday, November 20, 2008 9:59 PM
  • It would seem logical, to me at least, that the problem you are having with missing printers from the control panel list, could be explained by the DocumentsProperties() problem we are suffering.  Thought, I would think all the printers would be missing from the control panel list, since when we suffer the problem, all the printers listed via EnumPrinters() would fail on call to DocumentsProperties(); the 1st call to get size of DEVMODE record for in preparation for 2nd call to DocumenProperties to fetch a printer's properties.

    The more I think about the problem, it seems to be an unitialized variable, and that location in memory may have some proper initialization, usually 0, or some improper value that triggers the bug.  Just 'luck of the draw'.  I wish the folks at Microsoft could see the problem for themselves.

     

    Friday, November 21, 2008 8:20 PM
  • The printing problem noted in this forum affects some of Microsoft's own programs.  From VISTA64 and Intuit forums the following list of programs are affected - Wordpad and Word 2008. And other well known programs Adobe .pdf Reader, and Mozilla Firefox browser.   From Intuit forum there are these printing problem with Quicken 2008.

    This NOT an individual application problem, but a VISTA 64 bit problem, and Microsoft needs to 'take notice' and fix the problem.  This is a Microsoft's developer - MSDN - forum.  Does Microsoft have any forum moderators to take notice of this problem?


    Saturday, November 29, 2008 9:00 AM
  •  ddlnick wrote:
    The printing problem noted in this forum affects some of Microsoft's own programs.  From VISTA64 and Intuit forums the following list of programs are affected - Wordpad and Word 2008. And other well known programs Adobe .pdf Reader, and Mozilla Firefox browser.   From Intuit forum there are these printing problem with Quicken 2008.

    This NOT an individual application problem, but a VISTA 64 bit problem, and Microsoft needs to 'take notice' and fix the problem.  This is a Microsoft's developer - MSDN - forum.  Does Microsoft have any forum moderators to take notice of this problem?


    Wednesday, December 3, 2008 4:09 PM
  • Chesty La Rue said:

    Hi,

     

    I'm using Vista x64 and debugging a 32-bit program in Visual Studio 2008. I've found something that you are allowed to do if you're not an administrator, but you are not allowed to do if you are an administrator!

     

    If I call OpenPrinter to get a handle to any local printer, and then call DocumentProperties with the handle and the printer name (but every other parameter NULL or zero) to discover the size of the DEVMODE for that printer, it fails if the process is running in "elevated" mode. Of course, I'm most often running in this mode because I'm debugging within Visual Studio 2008, which warns me to always run the IDE elevated to administrator.

     

    In the call to OpenPrinter, it makes no difference whether I use PRINTER_ACCESS_ADMINISTER or PRINTER_ACCESS_USE as the access mask.

     

    When I call GetLastError/FormatMessage to discover a description for what has failed, FormatMessage doesn't return anything, which suggests this is a bug rather than a deliberate security decision.

     

    Obviously XP has no problem here. Also, x86 (32-bit) Vista always succeeds, regardless of whether the process is running elevated or not. But x64 Vista is only okay unless I run my program elevated (either for the purposes of debugging, or if I manually start it by right-clicking and choosing Run as administrator).

     

    Not surprisingly, this is causing serious problems debugging my program! Until it's resolved, Vista on x64 isn't a useful development environment.

     

    Has anyone else hit this? Is this a known issue, or is there a workaround or setting I can change to fix it?

     

    Thanks!

     



    Hi

    Did you ever get around this issue as it happens on our new Vista x86 Ultimate installation with Visual Studio 2008, when we run our app in debug and have the calls you mention we also get failures :(

    Is there a work around, any help much appreciated.

    Thanks
    Terry
    Friday, January 2, 2009 5:31 PM
  • I have this problem but what I have noticed and I have not read anywhere yet is on my system, all I have to do is restart my application and the printers work again.

    I print a lot of documents to Adobe PDF (I'm using CS4 so Acrobat 9) and it will give various error messages but will not print.  Nor will it print to any of my other printers (I print for a living so we have about a dozen printers to choose from).  In every application in every case, all I have to is restart the application.

    This is getting to be a real headache for me!  The file processing I do requires a lot of steps and when I have to close and restart an application it causes a lot of rework to be done.

    I always have a handful of programs running they include Microsoft Outlook, LogMeIn Pro, All-Way Sync, Avast Antivirus, and UltraMon (Dual Monitor Software).  I can only speculate that one of these programs would "cause" this error and I'm not sure when exactly I started having this problem but I've had all these programs installed since the first day I intalled Vista x64.

    The only other detail I can give is that I have a program (it's the one I usually notice this problem in first) called Mail Manager 2010 from BCC Software (Bowe Bell and Howell company).  When I installed this software (which is not "designed" for x64) Vista informed me that the program did not appear to run correctly the first time I ran it.  Vista made some sort of changes (automatically) and when I relaunced the program for the second time, the program worked fine and has since.

    I also run a RAM disk called RAM Drive from QSoft which is, of course, always running.

    My computer is built on Gigabyte P35-DS3 v2.0 motherboard, 8 GB of Corsair DDR2 800 RAM, 128 GB Western Digital Velociraptor drive, and a Intel QX9550 quad-core processor.

    I hope the information I have provided helps in finding the root cause of this problem and I would like to be contacted if anyone would like more information from me.

    Thank you,
    Chad Watson
    Dataprint Initiatives, LLC

    Wednesday, February 4, 2009 4:22 PM
  • Since my last post I decided to try some things to see if any one program was causing this problem.  I am running Office 2007 Enterprise and it appears that if I don't have any Office applications open when I try to print everything works fine.  If I have Outlook or Excel open (which I almost always do) then the problem occurs.

    It seems to be the WoW 32 bit thing which is causing the problem.

    Just thought I would add this tidbit.

    Thank you for any thoughts you may have.
    Thursday, February 5, 2009 10:45 PM
  • Hi,

    I am looking at the exactly same problem. In my case there is no elevation of privileges. 

    In the application I maintain, the simple call to DocumentProperties fails for unknown reason on one of the customers machine (Enumerate printer works fine followed by Open printer but then DocumentProperties to get the size of devmode fails). So I created a simple test application to isolate the problem. However, the test application seems to work perfectly fine on the same machine. So there is something fishy going on in my application.

    I will post my findings here.

    Desktop deployments are really becoming a nightmare these days. Every user seems to have a completely different problem (Yeh some will say that maybe you don't write code well enough. But the code is exactly what MS has recommended :) ). 

    Best Regards,
    Vishal
    Thursday, February 19, 2009 7:53 PM
  • Since my last post, I have been able to isolate this problem to one program and one process within that program.  I do not know the exact system calls that other have sighted here but  just the activities which cause the problem.

    I am using Bowe Bell and Howell's child company BCC Software's program called Mail Manager 2010 which is not actually designed for Vista x64.  When I initially installed the program, Vista gave me a warning that the program was not functioning properly and the program would not work correctly.  Then Vista took some sort of action automatically to "fix" the problem and the software performed as it should.

    The problem listed in my last post (and the reason for this forum) arose after that and only happens when this program is running.  More specifically, when I prepare my file to send it for processing the program packages the list a proprietary format and when I attempt to print the confirmation the printer spool fails.  I cancel the job, restart the program, redo the exact same process and the printers work the second time around.  Just an FYI, all programs that are running at the time the error occurs must be restarted in order to print again.  The exception to this is all Microsoft programs and all system programs like Notepad.  These programs continue to be able to print regardless of the error.

    I have contacted BCC and, of course, all they want to tell me is "well, the program is not designed for the OS you are running it on".  I had a mulit-day session with the Microsoft Office and OS technical support teams and they were not able to determine what the cause of the problem was, but assured me that if it is cause by a Microsoft application they would fix it. (Ha, Ha!)

    Again, I hope that the people on this forum who know actual development side of this problem can benefit from this information.

    Please post here if I can help provide any more information.
    Friday, March 6, 2009 5:37 PM
  • I have been able since my last post to eliminate this problem.  I am running the offending program, Bcc Software's Mail Manager 2010 as administrator and the problem goes away.  Now the only problem is I can't copy and paste into the program because of the elevated privileges. No biggie, but does anyone have a way to get around this?
    Tuesday, March 10, 2009 3:07 PM