Article ID: 2567869
Consider the following scenario:
Printer drivers are implemented as dynamic-link libraries (DLL) that are loaded into a process that is printing. Printer drivers are implemented as 64-bit DLLs on 64-bit versions of Windows. Printer drivers are implemented as 32-bit DLLs on 32-bit versions of Windows.
A 32-bit process cannot load 64-bit DLLs. Therefore, 64-bit versions of Windows support printing from 32-bit processes through the Splwow64.exe process. Splwow64.exe is a 64-bit process that can load 64-bit printer drivers and handles printing on behalf of 32-bit processes.
When an application calls the StartDoc function to print to the XPS Document Writer printer, the XPS Document Writer printer driver displays a Save As dialog box so that users can specify the name and location of the XPS file. The owner window of the dialog box is typically the active window of the thread that is calling the StartDoc function, and the dialog box will appear over the active window.
When a 32-bit application calls the StartDoc function on a 64-bit version of Windows, the Splwow64.exe process calls in to the XPS Document Writer printer driver on behalf of the 32-bit application. In this scenario, the Save As dialog box is unowned because the thread in the Splwow64.exe process does not have an active window. Additionally, the dialog box may appear behind the application that is printing because the Splwow64.exe process does not have permission to set the foreground window.
The StartDoc call does not return until the dialog box is dismissed, so the application may seem to stop responding.
The Save As dialog box has its own button in the Windows Explorer taskbar if it is created by the Splwow64.exe process. This is because the dialog box is unowned. The taskbar button also flashes when the Splwow64.exe process cannot set the foreground window.
To work around this behavior, you can access the Save As dialog box through the taskbar button. Or, you can press Alt+Tab to switch the focus to the dialog box.
Software developers can avoid this problem in their 32-bit applications by having these applications detect when the user is printing to the XPS Document Writer printer or to the Adobe PDF printer. The applicatiosn then specify the file path in the DOCINFO.lpszOutput structure member when the application is calling the StartDoc function. The printer driver will use the specified file instead of prompting the user for a file.
The third-party products that this article discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about the performance or reliability of these products.