We've a small remote Windows 2003 R2 server thats been crashing out at least once a week, since 3 days after I installed 1.5.0 on it (fresh install, no 1.4).
Doing some research my teams found some updates from MS about how print drivers should/shouldn't use memory.
We get event ID 333, then the system goes unstable. The servers been running for abour 3 years, and has 1Gb of RAM in it. Its basically a Domain Controller for a remote site, and doesn't do a lot else.
where did you see that PDFCreator uses Kernel Memory? Usually, this should not be the case. I am not the one in charge with the low-level driver side, but I think that our print monitor driver is run in User mode and thus should not be able to use Kernel memory at all.
But of course PDFCreator should not kill a server.
We had a second server recently spontaneously die yesterday (a 2008 server), only recent changes to both is PDFCreator 1.5 being added.
On the first server we saw event logs 333 and 2020. On the 2008 server there were no logs at all, but, the system wasn’t reachable, stopped running DHCP, CPU was elevated and we weren’t able to login (same symptoms as the 2003 server). Only common change in the past month is PDFCreator 1.5.0 being added.
The theory of the PDFCreator driver was by my colleague after some reading up of the driver side, and finding a PDFForge page entry that specified a GPO setting to enable kernel related drivers for PDFCreator to work
We’ve now disabled the pdfcreator.exe srvany process on the 2003 server to monitor it and see if that makes it stable.
Oddly, both of these instances of PDFCreator on these 2 servers are not yet ‘live’, they’re just in testing for a new distributed network of printer setups I was planning. So they really shouldn’t be actually doing anything.
Also - a little confused on your definition there of ‘print monitor driver’.
isn’t there a print driver section, that is part of the Print Spooler ?, that delivers raw files to a temporary folder, and then second, the Print Monitor .exe (pdfcreator.exe) that needs to be running and then picks up those files and converts them to PDFs ?
Thats how I understand it works at the moment, and why we need srvany running an instance of pdfcreator.exe
So, my understanding then is that the driver part would be running possibly in kernel memory, and that the pdfcreator.exe would be running in user memory
Using Process Explorer in admin mode, on the 2008 server I’m currently seeing stats as below for pdfcreator.exe, running since yesterdays reboot, and hasn’t as yet processed any jobs at all. Any chance we can compare ?
V memory: Private: 10486K, Peak 10504K, Virtual 95216K
Handles: 374338, peak: 374253 (both increasing slowing, about 1 per sec - normal ??)
Digging further - using Process Explorer I didn’t like the look of that handle count… so (and this is pure guesswork as I don’t know much about handles etc), but watching both our Production PDFCreator, which is 1.4 (and currently has about 1,000,000 handles), and my 2008 test machine, I can see that PDFCreators 1.4 and 1.5 both open new handles to the following regkey:
So - could it be possible that pdfcreator.exe is doing something with the registry, opening all these handles and exhausting the resources of the server ??
It could also be, that I don’t see this in my production machine (a Virtual Machine), because it has 4Gb of RAM to play with, and, its only a printer server (doesn’t do anything else), but, my two other remote-site testing servers also have to run DHCP, DNS, DC, WSUS, SQL, etc etc…
If I recall it right, the FAQ entry handles the integration of drivers for Windows 9x machines. They were kernel-mode drivers and they could not be distributed to the user from W7/2008 machines because of the group policy.
Regarding the drivers, we are using two custom parts: We have the pdfcmon.dll which is a port monitor driver. That catches the PostScript data (coming from the Windows PostScript driver) and passes that to PDFCreator. pdfcmon.dll should be running in user-mode. PDFCreator.exe takes the files and processes them. It definitely runs in user-mode.
But apparently there is some kind of problem. Please let me know if this still happens when you disable PDFCreator for a while. Of course, I hope that PDFCreator is not the origin of the problems. But if it is, we will try to fix this together with you.
Regarding the handles: There was a bug in the registry class and Frank has fixed that now. I can provide you with a preview version of PDFCreator 1.5.1, if you like. That will at least have the handles issue fixed.