We have a client that is using windows 2003 Terminal Server 64bit. The administrator can print to the amyuni printer with no problem. When the users log into the Terminal Server and try to print to the amyuni printer the job gets stuck in the amyuni print queue. Once we delete the errored job in queue the document gets created but does not save to our database.
We have tested this in the same type environment and have not experienced the trouble the customer is having. Any suggestion.
The install was done in install mode, and the users have full access to the HKEY_CURRENT_CONFIG\Software\(printer name) key.
64bit windows PrintJob Stuck in NOT FIXed!!!!!
We also have a similar scenario:
-Win2003 TS server
-our application has been installed on it from the console, using admin rights, so that we run with enough permissions to install the amyuni drivers (2.50f)
-from console, administrator can print to pdf without troubles
-from terminal server connection, administrator could not print
-from terminal server connection, users could not print
There was an old printer using the same drivers, with a similar name, so we removed it. We removed the printer, stopped spooler, restarted it, removed its drivers, then reinstalled it from console with admin rights.
Then we..
-fixed the permissions for the HKCC\Software branch in the registry
-removed the <printername> subkey so that it would get created again with the right permissions (it did) -> BTW, which permissions are we supposed to have there? all users full control to the key and subkeys?
-created a new local port and associated amyuni printer to it
after this,
-admin from console can print
-admin from TS connection CAN print
-users from TS still cannot print
So we gained for admin the ability to print in TS, but users still see their jobs hunging on printing (...and after you remove the jobs, some errors like "error loading printer driver"..)
Would like to make clear this printer setup and configuration worked flawlessly in almost every other system we installed it on, so far
What can we try to check to fix this?
What to look for?
Any help is welcome
-Win2003 TS server
-our application has been installed on it from the console, using admin rights, so that we run with enough permissions to install the amyuni drivers (2.50f)
-from console, administrator can print to pdf without troubles
-from terminal server connection, administrator could not print
-from terminal server connection, users could not print
There was an old printer using the same drivers, with a similar name, so we removed it. We removed the printer, stopped spooler, restarted it, removed its drivers, then reinstalled it from console with admin rights.
Then we..
-fixed the permissions for the HKCC\Software branch in the registry
-removed the <printername> subkey so that it would get created again with the right permissions (it did) -> BTW, which permissions are we supposed to have there? all users full control to the key and subkeys?
-created a new local port and associated amyuni printer to it
after this,
-admin from console can print
-admin from TS connection CAN print
-users from TS still cannot print
So we gained for admin the ability to print in TS, but users still see their jobs hunging on printing (...and after you remove the jobs, some errors like "error loading printer driver"..)
Would like to make clear this printer setup and configuration worked flawlessly in almost every other system we installed it on, so far
What can we try to check to fix this?
What to look for?
Any help is welcome
As an update to what I posted above, we've tried the same kind of setup on a Win2003 terminal-server machine which runs on a 32bit architecture (not x64). It worked like a charm without the need to fix permissions or change further settings...
In a try to reproduce our customer's worst case scenario, we installed our application and the amyuni printer (they're in the same MSI) without the "change user /install" command... and it worked, both for users and for administrators, both accessing from console and terminal server...
We also tried installing from console, works the same, no trouble even there... So this looks like a x64-specific issue...
As a side note (should it help) our application is a 32bit one.
Have anyone experienced a similar situation?
Thank you in advance for your hints!
In a try to reproduce our customer's worst case scenario, we installed our application and the amyuni printer (they're in the same MSI) without the "change user /install" command... and it worked, both for users and for administrators, both accessing from console and terminal server...
We also tried installing from console, works the same, no trouble even there... So this looks like a x64-specific issue...
As a side note (should it help) our application is a 32bit one.
Have anyone experienced a similar situation?
Thank you in advance for your hints!
We are having the exact same problem on a clients machine. Our application is 32bit as well. We have gone ahead and paid the support fee but Amyuni has not given us a resolution yet. We have gone over user rights for the registry and output directory. We have tried printing documents directly to the PDF driver without using our software. Interestingly enough I can directly print a notepad document to the PDF driver but a word document get stuck in the print spooler. A solution would be helpful. 
Printjobs stuck (Win2003 x64 TS) using Converter 2.50f
Today we connected to our customer's server, as admin users through the Console...
We cleaned everything cleanable, after everyone has closed his/her session.
In detail:
* change user /install
* removed our application
* removed the printer
* removed printer drivers (amyunid pdf converter 2.50f)
* stopped the spooler
* cleaned a couple of stale DLL under the spooler folder
* removed some registry keys left in HKCC\Software\<printer name> (and another one which now I don't remember...)
* restarted the spooler
* change user /execute
* change user /install
* installed our app, which should also create the printer, but didn't... it also didn't install printer drivers...
* so we installed both of them with an utility we made to do it (the sequence of DLL calls to install a printer which we found in Amyuni's documentation) and this time they did install
* checked permissions on the HKCC registry branch, which was ok
* change user /execute
* tried printing from our application, which worked
* disconnected from the console
With some hope we
* connected as a standard user via Terminal Server
* tried printing from our application... job stuck as usual
* removing the job gone wrong from the spooler queue, our app unfreezes and reports "error loading printer driver"
* no way
Then the interesting part:
* still connected via TS as a standard user
* tried running Process Monitor (PM) from sysinternals (using Run as... to let it run as an administrator)
* started our app, one click away from printing
* started capturing in PM
* started printing.. which stuck as always
* stopped capturing in PM
Filtering a bit, looking for Access Denied errors, we noticed that the spooler wanted to write to a C:\WINDOWS\SYSTEM32\AMYUNI file, which was obviously denied, since this is a key system folder, not a temporary one...
Terminal users had only read permissions on it, so they could not write. Giving them write access to it seemed to unlock all, since users were able to print (so far, at least...)
This explains why admins in TS were able to print (they had write access on that file).
But... this is quite weird, isn't it?
No application is supposed to be writing there (%windir%\system32), so it seems really odd.
Please, take a look at this...
PS: we could not try using the 3.x version, since the application they are using would not activate them using the new key... and this is a production environment, so we could not stop them longer than necessary...
PS2: we setup a server machine here with a similar configuration, in a effort to reproduce this... but could not reproduce the error, even if we did the same steps... all worked flawlessly...
We cleaned everything cleanable, after everyone has closed his/her session.
In detail:
* change user /install
* removed our application
* removed the printer
* removed printer drivers (amyunid pdf converter 2.50f)
* stopped the spooler
* cleaned a couple of stale DLL under the spooler folder
* removed some registry keys left in HKCC\Software\<printer name> (and another one which now I don't remember...)
* restarted the spooler
* change user /execute
* change user /install
* installed our app, which should also create the printer, but didn't... it also didn't install printer drivers...
* so we installed both of them with an utility we made to do it (the sequence of DLL calls to install a printer which we found in Amyuni's documentation) and this time they did install
* checked permissions on the HKCC registry branch, which was ok
* change user /execute
* tried printing from our application, which worked
* disconnected from the console
With some hope we
* connected as a standard user via Terminal Server
* tried printing from our application... job stuck as usual
* removing the job gone wrong from the spooler queue, our app unfreezes and reports "error loading printer driver"
* no way
Then the interesting part:
* still connected via TS as a standard user
* tried running Process Monitor (PM) from sysinternals (using Run as... to let it run as an administrator)
* started our app, one click away from printing
* started capturing in PM
* started printing.. which stuck as always
* stopped capturing in PM
Filtering a bit, looking for Access Denied errors, we noticed that the spooler wanted to write to a C:\WINDOWS\SYSTEM32\AMYUNI file, which was obviously denied, since this is a key system folder, not a temporary one...
Terminal users had only read permissions on it, so they could not write. Giving them write access to it seemed to unlock all, since users were able to print (so far, at least...)
This explains why admins in TS were able to print (they had write access on that file).
But... this is quite weird, isn't it?
No application is supposed to be writing there (%windir%\system32), so it seems really odd.
Please, take a look at this...
PS: we could not try using the 3.x version, since the application they are using would not activate them using the new key... and this is a production environment, so we could not stop them longer than necessary...
PS2: we setup a server machine here with a similar configuration, in a effort to reproduce this... but could not reproduce the error, even if we did the same steps... all worked flawlessly...
Last edited by lp on Wed Mar 12 2008, edited 1 time in total.
Hello,
Thanks for your information but we actually do not write or create any files in the user's windows\system32 directory. The only time we access this directory is when some type of post processing is used when generating the PDF document (example: appending, marching, adding watermarks etc). We access the CDIntf#.dll to perform the additional processing.
As you also encounter in your test environment you are unable to reproduce this issue. This is exactly what is also happening to us. We have a number of 64bit test servers (Vista, XP, 2003, 2008) and we are unable to replicate the issue.
If you can send any additional information regarding this issue to our tech support, this may help us in narrowing down the possible cause of the issue.
Thanks
Thanks for your information but we actually do not write or create any files in the user's windows\system32 directory. The only time we access this directory is when some type of post processing is used when generating the PDF document (example: appending, marching, adding watermarks etc). We access the CDIntf#.dll to perform the additional processing.
As you also encounter in your test environment you are unable to reproduce this issue. This is exactly what is also happening to us. We have a number of 64bit test servers (Vista, XP, 2003, 2008) and we are unable to replicate the issue.
If you can send any additional information regarding this issue to our tech support, this may help us in narrowing down the possible cause of the issue.
Thanks
Hello Jose,
thanks for the reply
I'm pretty sure you don't write anything down there, it is something every windows developer knows as a bad practise
However we traced the system with ProcessMonitor (sysinternals) when it was printing (well.. when was trying to..
) and a process involved in printing effectively requested write access to the AMYUNI file I told you..
So there is probably a glitch somewere, don't know whether in pdf drivers or spooler system or whatever else... So let's hunt it down
If it helps, we are printing through the DLL interface, nothing gets registered in the system during install (read: no activex interface, only DLL);
when installing our app we use LoadLibrary() to call cdintf.dll, which is placed inside our app's folder, in order to create the printer;
when printing we also use the same cdintf.dll;
in the app's folder we also have cdintf250.dll so that appending can work.
In our tests, however, we were not printing to an existing file, but to a new file in the user's desktop (on which he has full rights..)
Please also notice that everything seems to work fine on x64 systems which don't run Terminal Server services, it's specific to TS scenarios when connecting through TS...
If the trace we made on the customer's server might help you, let us know. We'll have to ask them if it is ok to send it to you, of course...
Thank you for the attention, hope this can help others in the end
thanks for the reply
I'm pretty sure you don't write anything down there, it is something every windows developer knows as a bad practise
However we traced the system with ProcessMonitor (sysinternals) when it was printing (well.. when was trying to..
) and a process involved in printing effectively requested write access to the AMYUNI file I told you..So there is probably a glitch somewere, don't know whether in pdf drivers or spooler system or whatever else... So let's hunt it down
If it helps, we are printing through the DLL interface, nothing gets registered in the system during install (read: no activex interface, only DLL);
when installing our app we use LoadLibrary() to call cdintf.dll, which is placed inside our app's folder, in order to create the printer;
when printing we also use the same cdintf.dll;
in the app's folder we also have cdintf250.dll so that appending can work.
In our tests, however, we were not printing to an existing file, but to a new file in the user's desktop (on which he has full rights..)
Please also notice that everything seems to work fine on x64 systems which don't run Terminal Server services, it's specific to TS scenarios when connecting through TS...
If the trace we made on the customer's server might help you, let us know. We'll have to ask them if it is ok to send it to you, of course...
Thank you for the attention, hope this can help others in the end
Hello,
A have a question regarding the directories you are referring to.
Gerick is referring to this directory “C:\WINDOWS\system32\spool\drivers\x64\3\Amyuni†and lp is referring this one “C:\WINDOWS\SYSTEM32\AMYUNIâ€. This question is how did these directories get created? These are not directories that our installer creates.
Thanks
Jose
A have a question regarding the directories you are referring to.
Gerick is referring to this directory “C:\WINDOWS\system32\spool\drivers\x64\3\Amyuni†and lp is referring this one “C:\WINDOWS\SYSTEM32\AMYUNIâ€. This question is how did these directories get created? These are not directories that our installer creates.
Thanks
Jose
Hello Jose
thank you for your attention... that's a good question
First of all, please notice that in my scenario “C:\WINDOWS\SYSTEM32\AMYUNI†is not a folder, it is a file..
I agree with you that probably the setup doesn't create it.
As a matter of fact (when printing) there is a process called "spoolsv.exe" which tries to write to that file after doing some registry reads, impersonating the user who is printing..
Here are some details from procmon:
Some more details on the file-creating call:
Also notice that giving write-permissions on such file to the users that should print (remote desktop users), they are able to print...
If that file does not have write permissions, the process gets tried again and again, about every 5 seconds and freezes the printing application until the application is killed or the printing queue is emptied...
HTH
Luke
thank you for your attention... that's a good question
First of all, please notice that in my scenario “C:\WINDOWS\SYSTEM32\AMYUNI†is not a folder, it is a file..
I agree with you that probably the setup doesn't create it.
As a matter of fact (when printing) there is a process called "spoolsv.exe" which tries to write to that file after doing some registry reads, impersonating the user who is printing..
Here are some details from procmon:
Code: Select all
Sequence: 8788
Event Class: Registry
Operation: RegOpenKey
Result: SUCCESS
Path: HKU\<userSSID>
Sequence: 8789
Event Class: Registry
Operation: RegOpenKey
Result: SUCCESS
Path: HKU\<userSSID>\Printers\DevModePerUser
Sequence: 8790
Event Class: Registry
Operation: RegCloseKey
Result: SUCCESS
Path: HKU\<userSSID>
Sequence: 8791
Event Class: Registry
Operation: RegQueryKey
Result: SUCCESS
Path: HKU\<userSSID>\Printers\DevModePerUser
SubKeys: 0
Values: 2
Sequence: 8792
Event Class: Registry
Operation: RegQueryValue
Result: NAME NOT FOUND
Path: HKU\<userSSID>\Printers\DevModePerUser\<ourPrinterName>
Length: 144
Sequence: 8793
Event Class: Registry
Operation: RegCloseKey
Result: SUCCESS
Path: HKU\<userSSID>\Printers\DevModePerUser
Sequence: 8794
Event Class: File System
Operation: CreateFile
Result: ACCESS DENIED
Path: C:\WINDOWS\system32\AMYUNI
Desired Access: Generic Write, Read Attributes
Disposition: OpenIf
Options: Sequential Access, Synchronous IO Non-Alert, Non-Directory File
Attributes: N
ShareMode: Read
AllocationSize: 0
Impersonating: <userSSID>Code: Select all
Description: Applicazione sottosistema spooler
Company: Microsoft Corporation
Name: spoolsv.exe
Version: 5.02.3790.3959
Path: C:\WINDOWS\system32\spoolsv.exe
Command Line: C:\WINDOWS\system32\spoolsv.exe
PID: 7544
Parent PID: 436
Session ID: 0
User: NT AUTHORITY\SYSTEM
Auth ID: 00000000:000003e7
Architecture: 64-bit
Virtualized: n/a
Integrity: n/aIf that file does not have write permissions, the process gets tried again and again, about every 5 seconds and freezes the printing application until the application is killed or the printing queue is emptied...
HTH
Luke