Closed Bug 168385 Opened 22 years ago Closed 20 years ago

Print causes BSOD / STOP / restart

Categories

(Core :: Printing: Output, defect)

Product:
Core
Component:
Printing: Output
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
mozilla1.3alpha

People

(Reporter: jrstrube, Assigned: rods)

References

(
URL
)

Details

(Keywords: crash, qawanted)

Attachments

(4 files)

Ethernet packet capture from print server when Mozilla BSOD happened
22.02 KB, application/octet-stream
Details
Ethernet Packet capture from successful print
101.08 KB, application/octet-stream
Details
printwin.exe
36.00 KB, application/octet-stream
Details
Malformed Packed from crash data
5.99 KB, application/pdf
Details 
Every time I attempt to print a page from the browser the system reboots. This
has caused a minor scramble on my C drive
What print driver were you using?
What version of Win 2k?
What version of Mozilla/Netscape?
Narrowed bug to be only print jobs sent to Xerox WorkCentre 390 printer of web
pages with frames. Printing of page to a networked HP Deskjet does not cause
crach or re-boot. My OS is Windows 2000 (Service Pack 3 installed). Printer is
Xerox WorkCentre 390 on LPT1, Data format=RAW, Driver=ssgn5.dll, Driver Version
4.00. Mozilla Version 1.o (Build 2002053012)
Hmmm, I can't find it at the moment.
I am also having this or a very similar problem.  I have Mozilla 1.1 running on
three computers.  The crash happens on two that are both Win2K (one SP2 and one
SP3) that are printing to the WC 390 through my wireless network.  The crash
does not happen on the one that is Win98SE that has the WC 390 connected to LPT:1.  

This does not consistently happen for me.  It seems to happen more often with
longer pages and also more often when the computers (both laptops) are farther
away from the the hub (lower bandwidth/larger latency).  From what I was
experiencing, I thought that perhaps this was related to 169689.  I just,
however, experienced the same crash (on the WIN2K sp 2 machine) using today's
(11/01/02) nightly build (Build ID: 2002110104), which I think has the fix for
169689 in it.

The blue screen says:

*** STOP: 0x0000001E (0xC0000005, 0x8046A7A2, 0x00000000, 0x1515150F)
K_MODE_EXCEPTION_NOT_HANDLED

*** Address 8046A7A2 base at 80400000, DateStamp 3ad7ad60 - ntoskrnl.exe

I also have the small (64KB) memory dump that I can attach if that would be helpful.

I know there are a lot of bugs to be stomped, but this one is very close to
having my wife going back to IE and I'd really rather avoid that.

If you need help testing or more information, I'm willing to help.  I just wish
I were enough of a programmer to try and figure this one out myself.


I tried it again with the current (2002111108) nightly build.  The printer I am
using (Xerox WC 390) has two driver versions for Win2K available on their web
site.  I tried them both (1.1.1 and 1.1.2) and reliable crashed the system as
described.  When I print the Mozilla start page is one that crashes.  

I'm going to post this comment to 166249, 160337, and 168385 because it may be
relevant to one or more of these bugs.

I am open to suggestions on additional testing I can do to help nail this down.
Dang. That's a strange bug. Well, that seems well reported enough.

-------------------------------------
So, these are the steps to reproduce, according to commenters:

1) Open www.mozilla.org
2) Print the page to Xerox WC-390 over the network.

The problem doesn't happen with IE.
-------------------------------------

Reporter --

What sort of printer driver is it? Do you know if it's a PCL or PostScript driver?

-M
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash
Summary: Causes re-boot of system → Print to Xerox WC 390 causes BSOD / restart
I don't know if it is PCL or Postscript.  The printer appears to support both.  

Also, this doesn't happen every time.  For me, it seems to be related to the
length of the page and the latency in the network.  If I were to guess, I would
guess something is timing out.
Any chance that you could get a packet capture of what goes on between you and
the printer? (www.ethereal.com has the best packet capture software for Windows.
Just start it before you print, and then somehow make sure it saves before it
crashes, I guess...)

-M
Yes,  I've downloaded it and installed it on the machine that the printer is 
connected to.  I should be able to capture up through the crash that way.  I'll 
post results as soon I can.
I captured this from the computer the WC 390 is hooked to using ethereal.  

3Com_1a:39:75, 192.168.111.3 is the print server
Agere_2b:ee:b2, 192.168.2 is the client machine on which Mozilla was running
(and caused BSOD.

Started data capture approx 1 second prior to hitting print and terminated once
BSOD core dump was complete.
Same conditions as previous attachment, except this time it didn't crash. 
Terminated DX once print job was completed on client.

Used Mozilla nightly build 2002111508 for both.
I tell ya what. This bug has enough data in it that I'll add mozilla1.3 to it.
With the specificity of the bug report, and the ethereal packet captures above,
it shouldn't take all that much engineer time to work this out.

Thanks for the stellar help, Scott!

-M
Keywords: mozilla1.3
Summary: Print to Xerox WC 390 causes BSOD / restart → Print to Xerox WC 390 causes BSOD / STOP / restart
*** Bug 160337 has been marked as a duplicate of this bug. ***
*** Bug 166249 has been marked as a duplicate of this bug. ***
I've copied the URL of a duplicate into this bug. Hopefully this will get us
better test data. If somebody could reduce that URL to a testcase, that would be
great.

-M
URL: http://www.webdav.org/deltav/WWW10/de...
Keywords: qawanted
Summary: Print to Xerox WC 390 causes BSOD / STOP / restart → Print causes BSOD / STOP / restart
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.3alpha
Attached file printwin.exe — 
Reporter: Please try out this simple app that is suppose to be a "generic"
representation of how we manipulate the DevMode objects during printing.
I downloaded and installed the app.  It did not BSOD the machine.  Just to make
sure the problem hadn't automagically fixed itself, next I went to the Mozilla
home page and printed that.  I saw the progress bar and less the a second after
it said complete, I got the BSOD.

I can often (but not always) print short pages successfully.  Generally, the
print job is complete (because I get a complete printout).  Is there an easy way
to point the application to a url?  I'm not confident that the success of the
one line print job tells you anything.

If there's more testing you want done, I'm ready and willing.
Had we decided in this bug whether images were an issue? I remember a bug where
printing worked ok with no images, but crashed badly (reboot) with them.
I don't think so.  In my experience, the likelihood of a crash is greater the
longer the print job takes.  Both of the machines I'm having problems with are
laptops that are connected to my network through a wireless segment of the network.

I am more likely to have a crash the longer the page that is being printed and I
am more likely to have a crash the farther the laptop is from the wireless
gateway (lower throughput, higher latency).

I have not seen anything that ties this crash to the content of the page.  If
you've got a big text only web site I can try, I'll go and see if it crashes.
It may be image related.  I printed several large text only pages and it didn't
crash, including:

http://bofh.ntk.net/Bastard1998-1.html

It did crash, however, on:

http://bofh.ntk.net/Bastard_1996-1.html

And it's also text only.  I'm going to take a look at the HTML and see if
anything jumps out.
I looked at the HTML on the two pages and a few differences stand out:

The page that does NOT crash (http://bofh.ntk.net/Bastard1998-1.html) is missing
the <HTML> and </HTML> tags.  

The pages that does crash (http://bofh.ntk.net/Bastard_1996-1.html) has the
<HTML> and <HTML> tags.  It also has a <body BGCOLOR="#0000CC" TEXT="#FFF33"
LINK="#FF3300"> tag and an <a HREF="Bastard_1996-2.html">Onward to Part
Two...</a> tag.

Other than that the pages look almost identical.
I captured some additional data locally and looked for a common thread.  

Each case in which a crash ocurred had a malformed packet.  The cases in which
it did NOT crash, there was no malformed packet.  The attachment is a PDF of
frame 40 from the crash2 attachment.  It has the same error (string goes past
end of frame) as the other crash case I looked at.

Knowing what this means is WAY out of my depth, but I submit in the hopes of
helping to narrow this down.  

BTW, still crashes on nightly build 2002120204.  Thanks for the effort on this
bug.  I find it truly vexing.
Still occurs with Mozilla 1.3 alpha, 2002121215.
Still occurs with 1.3b.
Does not occur in Netscape 7.01 Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.0.2) Gecko/20021120 Netscape/7.01 
OK.  Based on one night's testing I have reached the tenative conclusion that
this bug does not exist in 1.0.2.  That's great news for me because I can put
both of my WIN2K machines back to 1.0.2, but not so great for the project
because I'm only testing on the main path on one computer.

If the problem exists in 1.1 (my experience starts with 1.1, I never ran 1.0)
through 1.3b, but not in 1.0.2, does that provide any hints?
All right, then. That could be very helpful information.

Thank you for your devotion to this bug, Scott.

I thought that I might request it as blocking 1.3 with the new system, since it
might be passed over with just the keyword. Then at least we can know for sure
whether or not it's going to be fixed for 1.3.

-M
Flags: blocking1.3?
Flags: blocking1.3? → blocking1.3-
kitterman --

When you print, and the computer crashes, are there any system events logged?

In addition, is the WC 390 its own print server, or is it served from another
machine? If the WC 390 is its own print server, do you know how it's doing it?
That is, is it a proprietary O/S running on proprietary software, or a standard
O/S running on standard hardware? I know that some digital printers actually
have a Windows box inside.

You might also wish to check out the following articles in the MS KB:

http://support.microsoft.com/default.aspx?scid=kb;en-us;275678 (most applicable)

http://support.microsoft.com/default.aspx?scid=kb;en-us;811014

http://support.microsoft.com/default.aspx?scid=kb;en-us;329850

http://support.microsoft.com/default.aspx?scid=kb;en-us;287524

I suspect that Mozilla may be exposing a flaw in either Windows 2000 or the
drivers for your printer. If you are using the PCL driver, you may wish to try
the PostScript driver and see if that helps. If that doesn't help, you may wish
to actually call MS Tech Support. (I know, I know.)

The reason that I say this is, as I look over the MS KB, it seems that the only
way that the STOP could have occured in ntoskrnl.exe is if there's actually a
problem in Windows -- client software /should/ never be able to make a kernel
crash like that. (I'm not all that conversant with the kernel of Win2K [:-)],
but I know that theoretically software shouldn't be able to do that...)

-M
The WC 390 is connected to my LAN via another PC that runs WIN98.  That's
actually the PC I've been using to collect the crash data from (can't collect
the data off of the machine that crashes).

I agree that the actual root cause of the crash is likely a bug in either the
printer driver or WIN2K.  Xerox has two versions of the driver posted on-line. 
I've tried them both, both still crash.

I still think that this is a valid Mozilla bug because Moz is doing something
unusual.  I've been using Windows 2000 for the last two years to print to this
printer.  I have not had any other application cause a crash.  

Agreed that the OS shouldn't crash, but Moz is doing something strange to
stimulate it.  Additionally, the WC 390 is out of production, so Xerox isn't
going to fix the driver.  WIN2K is not the focus at MS.  If this is going to be
fixed, here is where it needs to be done.

Thanks for the questions.




My crash occurs on my system running Windows 2000 professional and the printer
is attaced directly to the machine
New information. I have replaced my WC390 with an HP OfficeJet K80xi and
attempting to print to this new printer does not cause a system restart. But the
print job dees not complete. The printer responds to the initial queing of the
jop but then does not respond thereafter. The system must be restarted to clear
the frozen print que. I can however print to an old HP DeskJet 694C attached to
 a W98se machine networked to my W2K machine without problem.

Problem does not exist in Netscape 7.02 (Mozilla/5.0 (Windows; U; Windows NT
5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02)

Current Mozilla 1.3b (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b)
Gecko/20030210)
I'm now running 1.0.2 on both machines that have had this problem and have not
seen a recurrence.  If there is testing that needs to be done, I'll install 1.4
(or whatever we're on at the moment) and test it.  AFAIK, this bug is still
there in 1.3.
I have just loaded the final Mozilla 1.3 and I am now able to print to my new HP
Officejet K80xi. Currnet version is:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312

Has the new version had any impact on those of you still using WC390's?

I have printed all pages that would have stalled or crashed under prior
installations.
A BSOD can't be Mozilla fault because Mozilla doesn't install kernel mode
drivers (running un CPU ring 0/1).
Mozilla triggers only a bug in your printer driver. You should ask the Tech
Support from the printer company for help.

It doesn't matter if you don't get a BSOD with other applications and/or other
Mozilla versions. You can only add a workaround for a printer driver bug in
Mozilla but that is not the rigfht way.



RE: Comment 34 - Yes, you are 100% right, but the printer in question is no
longer in production, so the chances of getting a driver update out of Xerox are
slim and none.  A Mozilla bandaid is the only realistic option for me.

The only choices I have are use a different browser or buy a different printer.
 As much as I like the current versions of Mozilla, I'm not buying a new printer
just so I can do so.  The good news is that 1.0.2 is not affected by this
problem, so on the two computers that I have that are potentially vulnerable,
I've downgraded them to 1.0.2.  

I don't like that and I am also unable to do as much testing as I used to on the
current versions.

This problem is absolutely not Mozilla's fault, but if it's going to be fixed,
Mozilla is where it will have to be fixed.  I know that this is not a problem
for virtually everyone, but for those of us affected it is a really big deal.  I
would hope that somewhere in the post-1.4 migration to the new application
architecture, there would be a way to take what is working in the 1.0.2 printing
code and use that as part of the path forward.
Still happens with Mozilla 1.5a and WIN2K SP4.
After some initial testing with Mozilla 1.5b, I am cautiously optomistic that
whatever the root cause of this bug it may have been resolved.  I don't see any
clear reason (based on release notes and searching through bugzilla) that this
would be the case, however it is possible that the fixes for bug 201767 or bug
217459 may have gotten this on too.  

I will try some more printing and see if I can make it crash like it used to.
Never mind.  Same crash still happens, although it is possible the frequency may
be somewhat reduced.
I've printed a number of times now using 1.6 final and it hasn't crashed yet. 
I'm not quite willing to declare victory, but at the very least the frequency of
this event (whatever the cause) is definitely less.
Scott or John, please reopen if you can still reproduce with Mozilla 1.7 beta or
newer. THanks.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
I have not experienced the problem since 1.4. Am now using Firefox 0.8 and have
occasional printer stalls.
Please reopen (since I'm not the original reporter, Bugzilla won't let me).

I have, so far, experience one crash with 1.7b.  The error messages were a bit
different and I neglected to write them down, so I was waiting until it happened
again to post it here.  I will provide that info after the next crash.

Although I do not believe that this has completely gone away, the level of
frequency is WAY down.  Fundamentally, I am sure that there is a printer driver
bug at the root of this, but as I've said in a previous comment, it's an old
printer so the driver isn't going to be updated and other programs (including
the Mozilla 1.0 branch) manage to exercise the driver in a way that doesn't
cause the crash.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: