Need a -log <PathToLogFile> commandline switch #1878
Comments
|
Possibly related to #301 where others have described "sometimes it works" The description at https://www.sumatrapdfreader.org/docs/Debugging-Sumatra.html mentions a hanging state but I have not tried to check how useful those are for running within a server. @kjk |
HenrikHolmIT
changed the title
HenrikHolmIT
changed the title
|
I should add that the print code is running form a Windows Service installed on said server. Its mostly works perfect but then those times where management has to print a huge amount of documents something locks up. And after a reboot of the server every thing works again. |
|
Server is a Windows Server 2012. Its old but it does work when it works. Our client is not able to upgrade to a more recent version of Windows Server due to legacy software compatibility. |
|
WinDbg is installed. Waiting for next hang to strip out a debug report |
|
Executing the commands on the debug site this is what I get: |
|
[edited to avoid others later confusion] Again I have not used the debugger tools however as the 1st warning is
Now the part where " I know what I dont know" the 0:000> .sympath Which in your case should POSSIBLY be Unfortunately without any related experience, I can't help you ensure that is corrected. |
|
I can verify that symbols have been downloaded via SumatraPDF UI before I loaded out the text above. I've restarted the server in the meantime and will have to report back when the problem comes back. Ill have to try to get it to load the correct symbols next time.
|
|
OK I was wrong your screenshot shows that without a crash the .dbg files are NOT in a \crashinfo subfolder, good luck |
|
We're not exactly experiencing a crash. Its a hang. We kill the SumatraPDF process after waiting 60 seconds. Dont know if that makes a difference. |
|
Could be a red herring but |
|
Its this line that downloaded them to this folder from SumatraPDF documentation/Debugging Sumatra link. I've copied the pdb files to that folder and will set WinDBG to use that folder as Symbols folder. .sympath+ SRVc:\symbolshttp://msdl.microsoft.com/download/symbols |
|
"A little knowledge is a dangerous thing" I "think" like in many "path" cases, you need to append default paths to include secondary locations such as SumatraPDF folder by using WibDbg commands but my suggestion is that I "think" c:\symbols may be a fallback location. |
|
I can confirm that it seems to load the symbols if I direct WinDBG to the symbols folder. Now just need it to hang again. |
|
I just logged at hang an here is the output. Please let me know if you see something that can be used. |
|
Thanks for report but have to admit to me it looks like hieroglyphics so need @kjk to do analysis. |
|
I do not know the size of the spool file. I did not know a spool file even existed? There do not seem to be anything wrong with the file causing the hang. It's a file downloaded form server on request and are usually one/two page documents. Code checks if the file is still open before sending it to the printer. I've tried to open a failed document with SumatraPDF application to see if it would show an error but it opened the document without problem. When these hangs happen it keeps happening until server is restarted. As mentioned code will monitor the process and end the process if not exited after 60 seconds. The next process will also hang until server is restarted. The Windows Service will get them all again and queue them for printing and this time SumatraPDF.exe process return 0 after milliseconds of runtime. I have yet to figure out how to push the server into a failed state. Sometimes it seems starts durring mass printing sessions and other times it seems to happen with a single print. But so far the only fix we have found has been to restart the server. |
|
Thanks for providing debug information. As you can see from: the hang happens inside Windows code (in Further comments:
I agree that some sort of |
|
@HenrikHolmIT |
|
I appreciate you looking into this. Now that we have pinpointed that it is an error with Windows might you have any ideas as to a possibility to restart some specific part on this windows machine to make gdi32.CreateDC (or NtRequestWaitReplyPort) function respond again? Our next test at customer is to move the printing service to other hardware. It is currently running on Windows Server 2012 and we would like for the customer to try running the service on newer OS software. Hopefully they'll be able to setup a Windows 10 machine that we can test on soon. About SumatraPDF not being ment for this kind of job I would just like to say that we looked into other solutions and so far SumatraPDF is the tool that has been most useful and that is the reason we chose to go with this tool. |
|
@HenrikHolmIT This could be a Windows bug. I found one reference to a bug in Windows Server 2012: https://stackoverflow.com/a/57630317/2898 |
|
Interesting case though it seems they have found a way they can reproduce by either having a KB installed or not. In this case it just seems to suddenly happen for no apparent reason. Our Windows Service is set to build 'Any CPU' and we actively select the 64 bit version of Sumatra on OS running 64 bits. We'll have to try to move the service to other hardware. Or instruct customer to reboot the server if/when their print jobs start failing. Thank you for all your help. |
|
@HenrikHolmIT
|
|
There is not much magic to our use of SumatraPDF. I first select which architecture to use and then launch it with parameters. As stated I've added a loop to detect a hang. Nothing wild. ` ` |
|
I thought you said your using 64bit that looks like 3.2-32.exe ?? |
|
The codeblock is cutting off the top of the code block. As you can see from the debug insert it is in fact the 64 bit version that is launched ModLoad: 000007f7 if (Environment.Is64BitProcess) |
|
OK forgot you said earlier it depends on architecture, I would still try 3.0 32bit |
|
We will most likely try to move the printing service to another machine first. I like to be on new hardware and software. If that machine experiences the same problem then maybe try that other version or maybe try to submit a support ticket at Microsoft. |
|
Was something changed on how printing is executed from version 3.0 forward? |
|
Yes the biggest change to printing methods was changed after 3.0 after that the code was modified to ONLY allow print as image default settings for fresh 3.0 include As it was compiled in older MS VC versions the underlying compilation may vary from more modern compilation, though if the faulty gdi primitive calls to the server are the root of the problem that part may not be different, but I having no idea, would simply try to see if there is a difference |
|
P.S the issue is graphics device related and thus some solutions mentioned checking graphics driver updates, however working headless your graphics are possibly not showing (stable or not) |
|
They have another piece of software running on the server that needs a logged in user so there is a desktop session. We use that session to monitor logs from the service and test different things. Service is running local system account. |
|
Possibly another red herring (if it works sometimes, why not every time ?) I emulated running with and without -silent, printing a small file to a virtual printer and requested the output file size, expecting it to differ with silent or be a constant without silent, to my surprise in neither case was it constant (feedback was generally variable). |
|
Well that was both inconclusive and as entertaining as watching paint dry. Using variable files both with and without silent in both cases I got similar, but not identical results. In general SumatraPDF does not exit until it has somehow confirmed print was completed (handed over to system) then eventually exits with error level 0, However the length of time that takes on my machine can be less than 1 minute for a couple of pages, but nearer 10 minutes for a larger 500 page report (Fast for a printer at roughly 50ppm) so first time with a large file I thought it may have hung, but it eventually completed building a 1.3GB output (Unsure how a physical printer might baulk at such a long stream but any glitch would take some time to perhaps declare as a failure) Using version 3.0 for comparison the small PDF files actually produced larger output from 3.0 so that would not be a help However for the 500 page report it ran faster in about 8 minutes but producing an output file about half the size (roughly 540 MB) so more efficient at roughly 60 ppm. I am happy to accept that process times are generally measured in minutes when printing but see your scripting is phrased in seconds. are you sure you are not killing a hanging man prematurely ? |
|
Are you sure you are not killing a hanging man prematurely? Yes. When this bug first appeared I did not monitor the process. I just started the process with Process.Start(startInfo).WaitForExit(); That worked fine inhouse. When service was installed at customer I was alerted of a strange behavior where print jobs would just stop processing for no reason. Customer was trying to restart the service but that failed because service executable would never exit because the PrintQueue thread was blocked because SumatraPDF.exe would never exit. That was when I made the 1 minute monitoring loop. When the hang occurs and the server is rebooted prints are executed in mere seconds on following attempts. So it seems that then the bug sets in there is no getting out of it. When the bug is active the process will wait forever until forcefully killed. Service receives a wakeup call from backend when printjobs a waiting to be sent to printer. Service will then start downloading documents one by one and sending them to the printer. So the sequence is this
This is the current 'gameloop' and if 20 printjobs are queued it will download them one at a time. If files are small and printing goes fast it will process those prints pretty quickly with the current gameloop. I may just want to put in a 5 second wait time between printjobs to maybe make the system ease off on the printer a little and see if that makes a difference. Also I dont know if our service is the only entity printing on this printer so it may just be swamped at times. Thank you for investigating further. |
Currently experience problems sending a lot of print jobs to a network printer from a server. These print jobs are created with the -silent -print-to commandline switches one after the other. This happens through out the day but at some point it is as though the server or the printer has had enough and SumatraPDF.exe starts to hang and will never exit. I had to start monitoring the process and if not finished after 60 seconds I have to kill the process. When it works it usually exits after a few seconds but when I does not work the process just hangs forever.
What I would like is a -log switch. Either with a or SumatraPDF.exe can just designate its own place where it wants to store the log file.
This would be something we would to able to use to trace why printing has stopped working. Most likely its a problem with the server or the printer but the -log switch would be great for debugging in the long run when debugging future problems.
Maybe logs would show how you could provide code to exit out with a proper exitcode if print job fails to send to printer.
The text was updated successfully, but these errors were encountered: