Closed Bug 448102 Opened 16 years ago Closed 12 years ago

Fx crashes when displaying PDF with Adobe Reader 9.0.0[@ kernel32.dll@0x442eb - AcroRd32.dll@0xef2be] (AcroRd32.exe invoked under firefox.exe process always crashes, if old sqlite.dll exists in System32 directory)

Categories

(Plugins Graveyard :: PDF (Adobe), defect)

Product:
Plugins Graveyard
Component:
PDF (Adobe)
Platform:
x86
Windows Vista
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: mahowi, Assigned: rsherry)

References

Details

(Keywords: crash, crashreportid, qawanted)

Crash Data

Attachments

(7 files, 2 obsolete files)

debug output (german)
8.66 KB, text/plain
Details
NSPR log (all:5) with local PDF in safe-mode
59.34 KB, text/plain
Details
NSPR log without crash on XP SP3 (2nd try)
36.15 KB, text/plain
Details
NSPR log (all:5) loading PDF in a different tab
496.62 KB, text/plain
Details
NSPR log (all:5) loading PDF in a different tab again
51.64 KB, text/plain
Details
new NSPR log with "Display PDF in Browser"=Off
51.89 KB, text/plain
Details
nspr log for comment #95
52.41 KB, text/plain
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.2pre) Gecko/2008072506 GranParadiso/3.0.2pre Mnenhy/0.7.5.20005
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.2pre) Gecko/2008072506 GranParadiso/3.0.2pre

Whenever I open a pdf, Firefox crashes. The PDF loads completely and gets displayed, but immediately crashes.

Reproducible: Always

Steps to Reproduce:
1. open any site with a pdf
2. pdf gets loaded and displayed
3. crash
Actual Results:  
Fx crashes


I'm currently using Adobe Reader 9.0.0 on Vista SP1.

I'm not always getting a crash report, but here's the latest crash ID: 26a24028-5822-11dd-91d7-001a4bd43e5c
Version: unspecified → 3.0 Branch
Exactly same issue recognized:
* Windows XP-Pro, SP-3
* Firefox 3.0.1 (german)
" Adobe 9

--
Hope you guys can fix that very soon.

Thx, Max
Blocks: 336184
PDF plugin of what version is loaded by Fx 3?  Loaded from where?
(1) about:config  plugin.expose_full_path=true
(2) about:plugins
(3) about:config  Reset plugin.expose_full_path (for safety)
Plugin nppdf32.dll gets loaded from C:\Program Files\Adobe\Reader 9.0\Reader\Browser
Version number of the dll is 9.0.0.332. AFAIK there's no newer version of Adobe Reader than 9.0.
Attached file debugger output (german) (obsolete) — 
I added the output of MS VC2008 debugger after crash.
Keywords: crash
Flags: blocking1.9.0.2?
Attached file debug output (german) — 
Sorry, the last one was unreadable.
Attachment #331895 - Attachment is obsolete: true
I uploaded a log file to http://www.mahowi.de/nspr.log. (NSPR log (all:5))

I also got a news crash id: 9a8e6c9e-5f8b-11dd-880d-001cc45a2c28
same problem (crashing Fx while open pdf files with adobe plugin) with all browsers. i've send some bug reports to your community.

Adobe Reader 9.0
Firefox 3.0.1
Windows XP SP3
PDF Download extension

hope you can solve this together with adobe.
good luck.
Are there any work arounds for this issue?
> Are there any work arounds for this issue?
See Bug 336184 Comment #14.


New Crash ID with latest nightly, clean profile and no AddOns.
  Crash ID: bp-18f37521-6565-11dd-ad76-001a4bd43ed6
(In reply to comment #10)
> > Are there any work arounds for this issue?
> See Bug 336184 Comment #14.
> 

Oh, sorry. I meant from a developer's perspective.

I have a PHP script that generates a PDF and I don't want the viewer's browser to crash while displaying the generated file in an <iframe>.

Anyway, after playing around, the problem I was encountering had to do with the "Allow fast web view" and/or "Allow speculative downloading in the background" options of Adobe Acrobat Reader. These control whether Reader uses the `Range` header of HTTP.

Unchecking those options would allow the browser to display the PDF. However, I have no control over whether visitors have these options checked. Thus I re-wrote my script and it appears to work now with those options checked.

I disabled "Allow fast web view" and "Allow speculative downloading in the background" in Adobe Reader for testing, but it doesn't help. Firefox still crashes.
Crash ID: bp-0d6a9fc2-67d3-11dd-86c8-001a4bd43ef6
Keywords: crashreportid
(In reply to comment #13)
> I disabled "Allow fast web view" and "Allow speculative downloading in the
> background" in Adobe Reader for testing, but it doesn't help. Firefox still
> crashes.
> Crash ID: bp-0d6a9fc2-67d3-11dd-86c8-001a4bd43ef6
> 

Perhaps there are multiple issues?

I just tried saving the output from my script as a PDF file, copying it to `htdocs/` of my Apache server, and visiting the URL to it in Firefox. Firefox crashes while trying to view this static file with "Allow fast web view" and "Allow speculative downloading in the background" both checked, but does not crash with both unchecked.

(In reply to comment #14)
> (In reply to comment #13)
> > I disabled "Allow fast web view" and "Allow speculative downloading in the
> > background" in Adobe Reader for testing, but it doesn't help. Firefox still
> > crashes.
> > Crash ID: bp-0d6a9fc2-67d3-11dd-86c8-001a4bd43ef6
> > 
> 
> Perhaps there are multiple issues?
> 
> I just tried saving the output from my script as a PDF file, copying it to
> `htdocs/` of my Apache server, and visiting the URL to it in Firefox. Firefox
> crashes while trying to view this static file with "Allow fast web view" and
> "Allow speculative downloading in the background" both checked, but does not
> crash with both unchecked.
> 

Also, after leaving one checked, but not the other, and visiting the URL to the static PDF, the culprit for me seems to be "Allow fast web view" solely; Firefox does not crash when opening the file with "Allow speculative downloading in the background" checked and "Allow fast web view" unchecked.
Note that I am using:
* Windows XP Service Pack 3, not Vista
* Firefox 3.0.1
* Adobe Reader 9.0.0

@work I'm also using XP SP3, Fx 3.0.1 and Adobe Reader 9.0.0 and don't get any crashes. I have to check the options of Adobe Reader there tomorrow.
If many PDFs(in many iframes) or very big PDF, Bug 383826 and Bug 368821 is possibly involved in your problem. With test case for Bug 368821(many iframes with PDF), phenomenon of Bug 383826 occurred and problem of Bug 368821(crash) occurred. See dependency tree for meta Bug 336184.

To Manfred H. Winter(bug opener), D. Trebbien:
Many PDF case or big PDF case? If yes, above bugs are possibly involved in problem. Does problem occur even when whole PDF data is already held in cache?

To D. Trebbien:
With "Allow fast web view" unchecked, does problem disappear when your IFRAME+PDF by PHP case too?
(In reply to comment #18)
> To Manfred H. Winter(bug opener), D. Trebbien:
> Many PDF case or big PDF case? If yes, above bugs are possibly involved in
> problem. Does problem occur even when whole PDF data is already held in cache?

For test cases of Bug 368821 Fx crashes with:
Crash ID: bp-698ad5e8-6829-11dd-96cf-001cc4e2bf68
Crash ID: bp-9ff66730-6829-11dd-abe7-001a4bd43ed6

But Fx crashes on my system with every PDF, even small ones. Even with a 52,5kB PDF loaded from my local harddrive I get a crash. So it doesn't have to be embedded in a webpage.
PDF gets loaded and rendered by Adobe Reader plugin without any errors. No "internal error" alert as in Bug 368826. Only after the PDF is fully loaded and rendered Firefox crashes. And there's no difference if I change Adobe Reader's options as mentioned in comment #12.

As mentioned above, there's no crash with Adobe Reader 9.0.0, Firefox 3.0.1 and Windows XP SP3 on my computer @work. I'll have to check what options Adobe Reader uses there.
Sorry, I meant Bug 383826 instead of Bug 368826 above.
(In reply to comment #18)
> If many PDFs(in many iframes) or very big PDF, Bug 383826 and Bug 368821 is
> possibly involved in your problem. With test case for Bug 368821(many iframes
> with PDF), phenomenon of Bug 383826 occurred and problem of Bug 368821(crash)
> occurred. See dependency tree for meta Bug 336184.
> 
> To Manfred H. Winter(bug opener), D. Trebbien:
> Many PDF case or big PDF case? If yes, above bugs are possibly involved in
> problem. Does problem occur even when whole PDF data is already held in cache?
> 
> To D. Trebbien:
> With "Allow fast web view" unchecked, does problem disappear when your
> IFRAME+PDF by PHP case too?
> 

There is only one embedded PDF, and the files sizes are not very large.

I know that Firefox crashes (with both options checked) when the PDF file sizes are: 1,079,024, 1,078,773, and 1,078,773 bytes. PDFs with sizes between 532,377 and 573,364 do not cause FF to crash (with both options checked).

Frustratingly, I generated a 10 page PDF with my new script this morning and Firefox crashes (with both options checked) while trying to display it in an <iframe> or as a standalone PDF (when I saved the output from the script, copied it to `htdocs/`, and visited its URL). Its file size is 609,348 bytes. Weirdly, a 9 page PDF I generated with the new script that was 604,892 bytes does *not* cause FF to crash when trying to display it in an <iframe> while both options are checked.

Note that the 1,079,024, 1,078,773, and 1,078,773 byte PDFs are each 8 pages.

WADA, to answer your question, yes, with "Allow fast web view" unchecked, PDFs generated by my old script displayed in an <iframe>. 

(In reply to comment #21)
> (In reply to comment #18)
> > If many PDFs(in many iframes) or very big PDF, Bug 383826 and Bug 368821 is
> > possibly involved in your problem. With test case for Bug 368821(many iframes
> > with PDF), phenomenon of Bug 383826 occurred and problem of Bug 368821(crash)
> > occurred. See dependency tree for meta Bug 336184.
> > 
> > To Manfred H. Winter(bug opener), D. Trebbien:
> > Many PDF case or big PDF case? If yes, above bugs are possibly involved in
> > problem. Does problem occur even when whole PDF data is already held in cache?
> > 
> > To D. Trebbien:
> > With "Allow fast web view" unchecked, does problem disappear when your
> > IFRAME+PDF by PHP case too?
> > 
> 
> There is only one embedded PDF, and the files sizes are not very large.
> 
> I know that Firefox crashes (with both options checked) when the PDF file sizes
> are: 1,079,024, 1,078,773, and 1,078,773 bytes. PDFs with sizes between 532,377
> and 573,364 do not cause FF to crash (with both options checked).
> 
> Frustratingly, I generated a 10 page PDF with my new script this morning and
> Firefox crashes (with both options checked) while trying to display it in an
> <iframe> or as a standalone PDF (when I saved the output from the script,
> copied it to `htdocs/`, and visited its URL). Its file size is 609,348 bytes.
> Weirdly, a 9 page PDF I generated with the new script that was 604,892 bytes
> does *not* cause FF to crash when trying to display it in an <iframe> while
> both options are checked.
> 
> Note that the 1,079,024, 1,078,773, and 1,078,773 byte PDFs are each 8 pages.
> 
> WADA, to answer your question, yes, with "Allow fast web view" unchecked, PDFs
> generated by my old script displayed in an <iframe>. 
> 

Hmmm. I visited the URL to the 10 page PDF I generated this morning in Internet Explorer 7.0.5730.13, and it crashed with:
Microsoft Visual C++ Runtime Library
Runtime Error!
Program: iexplore.exe

(In reply to comment #17)
> @work I'm also using XP SP3, Fx 3.0.1 and Adobe Reader 9.0.0 and don't get any
> crashes. I have to check the options of Adobe Reader there tomorrow.
> 

"Allow fast web view" and "Allow speculative downloading in the background" are both checked and no crashes on this computer.
Scratch the paragraph beginning with "Frustratingly ...". I have a couple of scripts which are responsible for printing out the <iframe> markup. One was using the old script. I regenerated the 10 page PDF with the script calling my new script and FF did not crash (with "Allow fast web view" checked).

The way my old PDF-generating script worked is that it would generate the PDF in memory and save to a temporary, static file. Then, the <iframe>-writing script would print an <iframe> with `src` set to the temporary file's URL.

The new way is for the <iframe>-writing script to print an <iframe> with `src` set to the URL of my PDF-generating script, which `echo`s the byte content with the proper `Content-Type` header.

Note that because the PDF is being generated by a dynamic PHP script, `Range` and `Content-Range` are not used, but when the <iframe> is to a static PDF file, `Range` and `Content-Range` *are* used. 

I think that this is good evidence for suspecting that somewhere, `Range` and `Content-Range` and being mishandled.

(In reply to comment #19)
> (In reply to comment #18)
> > To Manfred H. Winter(bug opener), D. Trebbien:
> > Many PDF case or big PDF case? If yes, above bugs are possibly involved in
> > problem. Does problem occur even when whole PDF data is already held in cache?
> 
> For test cases of Bug 368821 Fx crashes with:
> Crash ID: bp-698ad5e8-6829-11dd-96cf-001cc4e2bf68
> Crash ID: bp-9ff66730-6829-11dd-abe7-001a4bd43ed6
> 
> But Fx crashes on my system with every PDF, even small ones. Even with a 52,5kB
> PDF loaded from my local harddrive I get a crash. So it doesn't have to be
> embedded in a webpage.
> PDF gets loaded and rendered by Adobe Reader plugin without any errors. No
> "internal error" alert as in Bug 368826. Only after the PDF is fully loaded and
> rendered Firefox crashes. And there's no difference if I change Adobe Reader's
> options as mentioned in comment #12.
> 
> As mentioned above, there's no crash with Adobe Reader 9.0.0, Firefox 3.0.1 and
> Windows XP SP3 on my computer @work. I'll have to check what options Adobe
> Reader uses there.
> 

The problem does not appear to occur when the PDF is held in cache.

(In reply to comment #19)
> For test cases of Bug 368821 Fx crashes with:

I couldn't reproduce crash(nor freeze) with test case for Bug 368821(Adobe Reader 9.0.0, Firefox latest-trunk, MS Win-XP SP3, Core2-Duo PC), although I could observe some phenomena I reported to Bug 383826(blank IFRAMEs, error message in IFRAME) when I did many many Reload/Back/Forward while page loading.
All of "Display PDF in Browser", "Allow speculative downloading in the background", "Allow fast web view" is enabled in my test.
When PDFs are normally loaded in IFRAMEs, Adobe Reader(or PDF plugin) issued warning like next at middle of load of many PDFs, and loading stopped by the dialog, and the dialog was issued for each too many IFRAMEs, and PDF was not loaded in the too many IFRAMEs here after.
> "Unable to open new page because too many pages are open. Close pages to open new page"

To Manfred H. Winter(bug opener):

Your crash was upon Reload/Back(original report of Bug 368821)?
Or your crash occurred while normal loading of test case for Bug 368821?
To Manfred H. Winter(bug opener):

Why you can meet crash with any PDF file/test case at any location of any PDF file size, with PDF plugin of Adobe Reader 9.0.0, with any Adobe Reader option settings?
If crash occurs frequently even when usual PDF open with Adobe Reader 9.0.0, I think many bugs were already opened for Adobe Reader 9.0.0. (Many crash/freeze while usual PDF open were reported during Adobe Acrobat 6/Adobe Reader 7 era. See dependency tree for Bug 336184 with "Show Resolved").
Do you install any other Adobe's PDF related software such as Acrobat in addition to Adobe Reader 9.0.0?
Does crash occur frequently with -safe-mode of Firefox or new profile of Firefox?
Summary: Fx crashes when displaying PDF with Adobe Reader 9 plugin → Fx crashes when displaying PDF with Adobe Reader 9.0.0 plugin
(In reply to comment #27)
> Your crash was upon Reload/Back(original report of Bug 368821)?
> Or your crash occurred while normal loading of test case for Bug 368821?
> 

The crash occurred while normal loading.

(In reply to comment #28)
> Why you can meet crash with any PDF file/test case at any location of any PDF
> file size, with PDF plugin of Adobe Reader 9.0.0, with any Adobe Reader option
> settings?

Firefox always crashes regardless of size or location of PDF or Adobe Reader options. PDFs fully loads, gets rendered, then Firefox crashes.

> If crash occurs frequently even when usual PDF open with Adobe Reader 9.0.0, I
> think many bugs were already opened for Adobe Reader 9.0.0. (Many crash/freeze
> while usual PDF open were reported during Adobe Acrobat 6/Adobe Reader 7 era.
> See dependency tree for Bug 336184 with "Show Resolved").

I've gone through all bugs in depedency tree of Bug 336184, but couldn't find one that matches my crashes. I didn't have such problems with previous version of Adobe Reader.

> Do you install any other Adobe's PDF related software such as Acrobat in
> addition to Adobe Reader 9.0.0?

No, there's no other Adobe software than Adobe Reader 9.0.0.

> Does crash occur frequently with -safe-mode of Firefox or new profile of
> Firefox?
> 

Yes, even with -safe-mode or new profile Firefox crashes.

(In reply to comment #29)
> > Your crash was upon Reload/Back(original report of Bug 368821)?
> > Or your crash occurred while normal loading of test case for Bug 368821?
> The crash occurred while normal loading.

Question to clarify. No dialog by Adobe Reader(or PDF plugin) while loading?

You use Vista, but I use XP. Possibly due to too effective multi tasking of Vista for Adobe Reader. Do you use PC with multi-core or multi-CPU?
If yes, try CPU affinity setting(single CPU only) for Adobe Reader 9.0.0.
 - Start stand alone Adobe Reader 9.0.0(acrord32.exe) with CPU affinity set.
   (AFAIK, PDF plugin doesn't start new acrord32.exe if already started.)
 - Start Fx, and open PDF
To D. Trebbien:

Test case for Bug 368821 seems to be a good litmus test for us.
Can you re-produce crash with the test case on your XP SP3? (I also use XP SP3)
(If normally loaded, please try Reload/Back/Forward/Stop while loading or after loading.) 
(Correction of Comment #30)

Adobe Reader 9.0.0 doesn't look to create stand alone process of AcroRd32.exe.
When test case for Bug 368821 with "Display PDF in Browser"=Off, new(only one) window named attachment.cgi was generated, and it's process was firefox.exe. Adobe Reader 9.0.0 seems to kick acrord32.exe as a window under process of firefox.exe.
So CPU affinity should be set to firefor.exe when test. 

Signature	kernel32.dll@0x442eb
UUID	26a24028-5822-11dd-91d7-001a4bd43e5c
Time	2008-07-22 12:12:08-07:00
Uptime	59
Product	Firefox
Version	3.0.2pre
Build ID	2008072006
OS	Windows NT
OS Version	6.0.6001 Service Pack 1
CPU	x86
CPU Info	AuthenticAMD family 15 model 72 stepping 2
Crash Reason	0xc06d007f / 0x00000000
Crash Address	0x76be42eb
Comments	
Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 	kernel32.dll 	kernel32.dll@0x442eb 	
1 	AcroRd32.dll 	AcroRd32.dll@0xef2be 	
2 	AcroRd32.dll 	AcroRd32.dll@0x70d383 	

Thread 0
Frame 	Module 	Signature [Expand] 	Source
0 	js3250.dll 	js_DefineProperty 	mozilla/js/src/jsobj.c:3032
1 	xul.dll 	DefinePropertyIfFound 	mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp:488
2 	xul.dll 	XPC_WN_NoHelper_Resolve 	mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp:730
3 	js3250.dll 	js_LookupPropertyWithFlags 	mozilla/js/src/jsobj.c:3386
4 	js3250.dll 	js_GetPropertyHelper 	mozilla/js/src/jsobj.c:3645
5 	js3250.dll 	js_Interpret 	mozilla/js/src/jsinterp.c:4283
6 	js3250.dll 	js_Invoke 	mozilla/js/src/jsinterp.c:1313
7 	js3250.dll 	JS_CallFunctionValue 	mozilla/js/src/jsapi.c:5054
8 	xul.dll 	nsXPCWrappedJSClass::CallQueryInterfaceOnJSObject 	mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp:279
9 	xul.dll 	nsXPCWrappedJS::GetNewOrUsed 	mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp:322
10 	xul.dll 	XPCConvert::JSData2Native 	mozilla/js/src/xpconnect/src/xpcconvert.cpp:1034
11 	xul.dll 	XPCWrappedNative::CallMethod 	mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:2234
12 	xul.dll 	XPC_WN_GetterSetter 	mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp:1497
13 	js3250.dll 	js_Invoke 	mozilla/js/src/jsinterp.c:1297
14 	js3250.dll 	js_InternalInvoke 	mozilla/js/src/jsinterp.c:1369
15 	js3250.dll 	js_NativeSet 	mozilla/js/src/jsobj.c:3613
16 	js3250.dll 	js_SetPropertyHelper 	mozilla/js/src/jsobj.c:3921
17 	js3250.dll 	js_Interpret 	mozilla/js/src/jsinterp.c:4513
18 	js3250.dll 	js_Invoke 	mozilla/js/src/jsinterp.c:1313
19 	xul.dll 	nsXPCWrappedJSClass::CallMethod 	mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp:1523
20 	xul.dll 	nsXPCWrappedJS::CallMethod 	mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp:559
21 	xul.dll 	PrepareAndDispatch 	mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:114
22 	xul.dll 	SharedStub 	mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:141
23 	xul.dll 	nsSAXXMLReader::HandleEndElement 	mozilla/parser/xml/src/nsSAXXMLReader.cpp:153
24 	xul.dll 	xul.dll@0x6f4e9f 	

Filename 	Version 	Debug Identifier 	Debug Filename
AcroRd32.dll 	9.0.0.332 	9F3DBD2C4D9F41EDA7418BA3C816532C2 	AcroRd32.pdb

msintov: i know this isn't your group, but could you please find someone who can be the interface from adobe for this plugin? thanks
Assignee: nobody → msintov
Component: General → Plug-ins
Product: Firefox → Core
QA Contact: general → plugins
Summary: Fx crashes when displaying PDF with Adobe Reader 9.0.0 plugin → Fx crashes when displaying PDF with Adobe Reader 9.0.0 plugin [@ kernel32.dll@0x442eb - AcroRd32.dll@0xef2be]
Version: 3.0 Branch → 1.9.0 Branch
(In reply to comment #30)
> (In reply to comment #29)
> > > Your crash was upon Reload/Back(original report of Bug 368821)?
> > > Or your crash occurred while normal loading of test case for Bug 368821?
> > The crash occurred while normal loading.
> 
> Question to clarify. No dialog by Adobe Reader(or PDF plugin) while loading?
> 

Right, there's no dialog by Adobe Reader while loading. Everything looks alright until PDF is fully loaded.

> You use Vista, but I use XP. Possibly due to too effective multi tasking of
> Vista for Adobe Reader. Do you use PC with multi-core or multi-CPU?
> If yes, try CPU affinity setting(single CPU only) for Adobe Reader 9.0.0.
>  - Start stand alone Adobe Reader 9.0.0(acrord32.exe) with CPU affinity set.
>    (AFAIK, PDF plugin doesn't start new acrord32.exe if already started.)
>  - Start Fx, and open PDF
> 

(In reply to comment #32)
> (Correction of Comment #30)
> 
> So CPU affinity should be set to firefor.exe when test. 
> 

I have a dual core processor (AMD Turion64 X2). I've set CPU affinity for firefox.exe and opened a PDF. Same crash!
Crash ID: bp-4dd730a8-6a1d-11dd-9809-001321b13766

I also tried setting CPU affinity to AcroRd32.exe. Didn't help either.

Not going to block on an UNCONFIRMED bug. We need some better QA here to determine what to do.
Flags: blocking1.9.0.2? → blocking1.9.0.2-
Keywords: qawanted
Following is a thread(1st page of 3 pages) in a support forum.
http://support.mozilla.com/tiki-view_forum_thread.php?locale=lt&forumId=1&comments_threshold=0&comments_parentId=80067&comments_offset=0&comments_per_page=20&thread_style=commentStyle_plain
Some users say crash disappeared by:
  - Uninstall of extension(not disable only)
  - Put PDF file local
  - ( Needless to say, disable Adobe's PDF plugin :-) )

During test with test case for Bug 368821(IFRAME case. I reduced number of IFRAMEs to avoid warning dialog of "too many page"), following error message was displayed in a IFRAME.
> Secure Connection Failed
> An error occurred during a connection to bugzilla.mozilla.org.
> SSL received a record with an incorrect Message Authentication Code.
> (Error code: ssl_error_bad_mac_read)
> The page you are trying to view can not be shown because the authenticity
> of the received data could not be verified.
>     * Please contact the web site owners to inform them of this problem.
When I saw this error previously, "Reload" displayed PDF in all IFRAME normally.
But when recent test, all other IFRAMEs was kept blank upon "Reload", and any load of test case(both IFRAME and EMBED) displayed blank IFRAMEs only.
This looks for me that plugin is active/normal, but AcroRd32.exe doesn't return data to plugin or doesn't render PDF data (possibly wait/dead lock at somewhere, instead of temporary failure).
If error is in AcroRd32exe, problem like above occurs, and if error is nppdf32.dll's crash, crash of Fx occurs, and if error is wait/loop in AcroRd32.exe and/or nppdf32.dll, freeze of Fx occurs.
(In reply to comment #31)
> To D. Trebbien:
> 
> Test case for Bug 368821 seems to be a good litmus test for us.
> Can you re-produce crash with the test case on your XP SP3? (I also use XP SP3)
> (If normally loaded, please try Reload/Back/Forward/Stop while loading or after
> loading.) 
> 

I downloaded the test case to my `htdocs/` folder and visited the URL in Firefox. It loaded without crashing.

I think that when I saw this bug report, I was eager to contribute my experiences in the hope of getting this fixed more quickly. However, after reviewing Mr. Winter's original comment, I am not sure that we have the same problem. For one, my problematic PDFs do not render -- at all. It seems as though the moment Firefox tries to initialize the Adobe Reader plugin on the PDFs I am generating, Firefox crashes.

I searched for other bugs with "PDF crash" and none seem to match what I am experiencing.

Also, when I ask co-workers to view the problematic PDFs, their browsers consistently crash. Additionally, we use a wide variety of computing equipment (laptops to desktops with different Intel processors), so I am not sure that hardware is the issue. If it helps, though, I am using a Core 2 Duo processor, 1.99 GHz.
(In reply to comment #37)
> Also, when I ask co-workers to view the problematic PDFs, their browsers consistently crash.

Can you open it to public for duplication test?
(In reply to comment #36)
> Following is a thread(1st page of 3 pages) in a support forum.
> http://support.mozilla.com/tiki-view_forum_thread.php?locale=lt&forumId=1&comments_threshold=0&comments_parentId=80067&comments_offset=0&comments_per_page=20&thread_style=commentStyle_plain
> Some users say crash disappeared by:
>   - Uninstall of extension(not disable only)
>   - Put PDF file local
>   - ( Needless to say, disable Adobe's PDF plugin :-) )
> 

I tried it with a clean new profile without extensions and no plugins other than pdf plugin. Same crash again.
I also deleted extensions.rdf and downloads.sqlite as mentioned in the forum thread, but this didn't help either.
Of course I can download PDF and open it with Adobe Reader directly, but this wouldn't solve the problem.
(In reply to comment #39)
> I tried it with a clean new profile without extensions and no plugins other
> than pdf plugin. Same crash again.

Does it mean that you never succeeded to open PDF with Fx/Adobe Reader 9.0.0, with "Display PDF in Browser"=On, on with Vista? Or you succeeded several times in the past.
If latter, is there any difference between crash case and successful case?
(PDF size, location:https/http/local, Win's amin user/non-admin user, ...)

By test with IE7, I found difference between Fx and IE;
  - When IE7, standalone AcroRd32.exe process is invoked.
    (this is same behavior of Adobe Reader 6/7/8+Firefox)
  - When Fx 3/Fx trunk, standalone AcroRd32.exe process is not invoked.
    AcroRd32.exe is executed under Fx's process.
    This is easily viewed by "Display PDF Browser="Off.
While testing with IE7+Adobe Reader 9.0.0+"Display PDF in Browser="On" under admin user, I saw progress meter which says "checking update of Adobe Reader".
This is very normal, because I enable automatic update check and Adobe Reader 9.0.0 runs under admin-user. And it's never produce problem because it's executed  by standalone ActoRd32.exe.
When Firefox, this kind of excess activity(open dialog, progress meter) can interfere comunication among Fx, nppdfd32.dll, and AcroRd32.exe under firefox.exe process. (Adobe Reader 8.0.1 successfully issued alert of Bug 383826 Comment #1, but Adobe Reader 8.0.0 crashed or froze when tried to issue the alert.)

To Manfred H. Winter:  
Crash occurs with both admin-user and non-admin user?  
(In reply to comment #38)
> (In reply to comment #37)
> > Also, when I ask co-workers to view the problematic PDFs, their browsers consistently crash.
> 
> Can you open it to public for duplication test?
> 

I am sorry, but I can not release it.
(In reply to comment #40)
> (In reply to comment #39)
> > I tried it with a clean new profile without extensions and no plugins other
> > than pdf plugin. Same crash again.
> 
> Does it mean that you never succeeded to open PDF with Fx/Adobe Reader 9.0.0,
> with "Display PDF in Browser"=On, on with Vista? Or you succeeded several times
> in the past.
> If latter, is there any difference between crash case and successful case?
> (PDF size, location:https/http/local, Win's amin user/non-admin user, ...)
> 

Last time I could successfully load a PDF in Firefox was with Adobe Reader 8.x. AFAIR I never suceeded with Adobe Reader 9.0.0.

> To Manfred H. Winter:  
> Crash occurs with both admin-user and non-admin user?  
> 

Yes, it occurs with both. I have to check for updates as admin, so I regularly test if it works under an admin account.

(In reply to comment #37)
>(snip)
> However, after reviewing Mr. Winter's original comment, I am not sure that we have the same problem.

D. Trebbien, I thought so too, and I'm now sure "never be same", by bug opener's last comment.    

> For one, my problematic PDFs do not render -- at all.
>(snip)
> Also, when I ask co-workers to view the problematic PDFs, their browsers consistently crash.
>(snip)

D. Trebbien:

Your case sounds for me:
 (a) Crash with specific PDF only, as you say.
 (b) Your crash seems to be able to bypassed by "Allow fast web view"=Off.
If you have test PDF which can be opened to public, open separate bug with setting dependency to meta Bug 336184, please.
(In reply to comment #42)
> Last time I could successfully load a PDF in Firefox was with Adobe Reader 8.x.
> AFAIR I never succeeded with Adobe Reader 9.0.0.

I usually suspect followings first in such case.
(1) Interfere by Anti virus software/Firewall software on PC.
(2) Interfere by garbages in Temp directory.
(3) Interfere by Vista specific feature such as UAC.
(4) Due to Vista's enhanced multi-tasking (no problem on my Win-XP SP3)
    (this doesn't seem to be cause, because CPU affinity didn't help)
(5) Due to Vista's enhancement memory management etc. (no problem on my Win-XP)

To Manfred H. Winter(bug opener):
(Q1) What happens when Anti Virus software is disabled?
     What happens when Personal Firewall Software is disabled?
(Q2) Are many garbages are kept in your temp directory?
     ("DIR %TEMP% /S" at "Command Prompt")
     If many garbages exists, what happens if temp directory is cleaned up?
     (Fx uses "plugtmp"/"plugtmp-N" directory under %TEMP% to pass pdf data)
(In reply to comment #6)
> I uploaded a log file to http://www.mahowi.de/nspr.log. (NSPR log (all:5))
> I also got a news crash id: 9a8e6c9e-5f8b-11dd-880d-001cc45a2c28

Attached is HTTP GET related log for your PDF file in your log.
"HTTP GET with Range: bytes=..." is issued by Fx because your server returned "Accept-Ranges:bytes" to initial "HTTP GET" and the initial "HTTP GET" failed at middle of download.   
And your server returned "206 Partial Content" with following Content-Type: header.
> Content-Type: multipart/byteranges; boundary=489310216cf3

> Following is HTTP header retunrned for http://www.barchetta-lexikon.de/pdf/s021_frontumbau.pdf
> HTTP/1.x 200 OK
> Date: Sat, 16 Aug 2008 12:50:02 GMT
> Server: Apache/1.3.34 Ben-SSL/1.55
> Last-Modified: Sun, 30 Mar 2008 01:49:22 GMT
> Etag: "178e464-8729e-47eef1a2"
> Accept-Ranges: bytes
> Content-Length: 553630
> Keep-Alive: timeout=2, max=200
> Connection: Keep-Alive
> Content-Type: application/pdf

To Manfred H. Winter(bug opener):

multipart/byteranges in "206 Partial Content" response is correct use of "206" & multipart/byteranges for content previously sent with Content-Type:application/pdf?
(Note: Even if it's one of reasons of your crash, I can't explain your crash even with local PDF file)

(Attached: HTTP GET/Response in your log)
> (snip)
> 00001106 3.05120873 [13984] 0[928140]: http request [
> 00001107 3.05128741 [13984] 0[928140]:   GET /pdf/s021_frontumbau.pdf HTTP/1.1
> 00001108 3.05134392 [13984] 0[928140]:   Host: www.barchetta-lexikon.de
> 00001109 3.05139613 [13984] 0[928140]:   User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.2pre) Gecko/2008073106 GranParadiso/3.0.2pre Mnenhy/0.7.5.20005
> 00001110 3.05145335 [13984] 0[928140]:   Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> 00001111 3.05152559 [13984] 0[928140]:   Accept-Language: de-DE,de;q=0.8,de-de;q=0.7,en-US;q=0.5,en;q=0.3,en-us;q=0.2
> 00001112 3.05161262 [13984] 0[928140]:   Accept-Encoding: gzip,deflate
> 00001113 3.05168080 [13984] 0[928140]:   Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> 00001114 3.05172062 [13984] 0[928140]:   Keep-Alive: 300
> 00001115 3.05176282 [13984] 0[928140]:   Connection: keep-alive
> 00001116 3.05181241 [13984] 0[928140]:   Range: bytes=549534-553629,549534-549535
> (snip)
> 00001877 3.20403504 [13984] 12856[928b40]: http response [
> 00001878 3.20409036 [13984] 12856[928b40]:   HTTP/1.1 206 Partial Content
> 00001879 3.20414400 [13984] 12856[928b40]:   Date: Fri, 01 Aug 2008 13:31:13 GMT
> 00001880 3.20424485 [13984] 12856[928b40]:   Server: Apache/1.3.34 Ben-SSL/1.55
> 00001881 3.20426512 [13984] 12856[928b40]:   Last-Modified: Sun, 30 Mar 2008 01:49:22 GMT
> 00001882 3.20431924 [13984] 12856[928b40]:   Etag: "178e464-8729e-47eef1a2"
> 00001883 3.20441055 [13984] 12856[928b40]:   Accept-Ranges: bytes
> 00001884 3.20456529 [13984] 12856[928b40]:   Content-Length: 4306
> 00001885 3.20462489 [13984] 12856[928b40]:   Keep-Alive: timeout=2, max=200
> 00001886 3.20467925 [13984] 12856[928b40]:   Connection: Keep-Alive
> 00001887 3.20473266 [13984] 12856[928b40]:   Content-Type: multipart/byteranges; boundary=489310216cf3
> 00001888 3.20478630 [13984] 12856[928b40]:   X-Antivirus: avast! 4
> 00001889 3.20483971 [13984] 12856[928b40]:   X-Antivirus-Status: Clean
> 00001890 3.20489526 [13984] 12856[928b40]: ]
> (snip)
> 00002452 3.86567354 [13984] 0[928140]: http request [
> 00002453 3.86570811 [13984] 0[928140]:   GET /pdf/s021_frontumbau.pdf HTTP/1.1
> 00002454 3.86573815 [13984] 0[928140]:   Host: www.barchetta-lexikon.de
> 00002455 3.86577320 [13984] 0[928140]:   User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.2pre) Gecko/2008073106 GranParadiso/3.0.2pre Mnenhy/0.7.5.20005
> 00002456 3.86580539 [13984] 0[928140]:   Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> 00002457 3.86583734 [13984] 0[928140]:   Accept-Language: de-DE,de;q=0.8,de-de;q=0.7,en-US;q=0.5,en;q=0.3,en-us;q=0.2
> 00002458 3.86586738 [13984] 0[928140]:   Accept-Encoding: gzip,deflate
> 00002459 3.86589837 [13984] 0[928140]:   Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> 00002460 3.86592698 [13984] 0[928140]:   Keep-Alive: 300
> 00002461 3.86596012 [13984] 0[928140]:   Connection: keep-alive
> 00002462 3.86599088 [13984] 0[928140]:   Range: bytes=65536-549533,65536-65537
> 00002463 3.86603403 [13984] 0[928140]:   Cookie: __utma=247141911.2019932738.1207960915.1217567161.1217568800.53; __utmz=247141911.1217112794.47.17.utmccn=(referral)|utmcsr=barchetta-forum.de|utmcct=/smf/index.php/topic,6696.msg70723/topicseen.html|utmcmd=referral; blex_article_1=a024; blex_article_2=m001; blex_article_3=l010; blex_article_4=z009; blex_article_5=g012; cookname=mahowi; cookpass=gei034fk
> 00002464 3.86606431 [13984] 0[928140]: ]
> (snip)
> 00002615 3.89991689 [13984] 12856[928b40]: http response [
> 00002616 3.90031672 [13984] 12856[928b40]:   HTTP/1.1 206 Partial Content
> 00002617 3.90038204 [13984] 12856[928b40]:   Date: Fri, 01 Aug 2008 13:31:13 GMT
> 00002618 3.90042019 [13984] 12856[928b40]:   Server: Apache/1.3.34 Ben-SSL/1.55
> 00002619 3.90045738 [13984] 12856[928b40]:   Last-Modified: Sun, 30 Mar 2008 01:49:22 GMT
> 00002620 3.90049410 [13984] 12856[928b40]:   Etag: "178e464-8729e-47eef1a2"
> 00002621 3.90053034 [13984] 12856[928b40]:   Accept-Ranges: bytes
> 00002622 3.90058422 [13984] 12856[928b40]:   Content-Length: 484205
> 00002623 3.90061998 [13984] 12856[928b40]:   Keep-Alive: timeout=2, max=198
> 00002624 3.90069246 [13984] 12856[928b40]:   Connection: Keep-Alive
> 00002625 3.90072584 [13984] 12856[928b40]:   Content-Type: multipart/byteranges; boundary=489310216cf3
> 00002626 3.90085769 [13984] 12856[928b40]: ]
> (snip)
Assignee: msintov → nobody
(In reply to comment #44)
> (Q1) What happens when Anti Virus software is disabled?
>      What happens when Personal Firewall Software is disabled?

I disabled avast! Antivirus and Windows Firewall (no other PFW installed), doesn't help.

> (Q2) Are many garbages are kept in your temp directory?
>      ("DIR %TEMP% /S" at "Command Prompt")
>      If many garbages exists, what happens if temp directory is cleaned up?
>      (Fx uses "plugtmp"/"plugtmp-N" directory under %TEMP% to pass pdf data)
> 

There were a lot of files in %TEMP% (about 28.000!), so I cleared %TEMP. This doesn't help either.
I also cleared the cache with no result.
new NSPR log (all:5), this time with Fx in safe-mode while loading a PDF from my harddrive
(In addition to Comment #45)

RFC 2068 says: (http://www.faqs.org/rfcs/rfc2068.html)
> 4.4 Message Length
>(snip)
>   4. If the message uses the media type "multipart/byteranges", which is
>     self-delimiting, then that defines the length. This media type MUST
>     NOT be used unless the sender knows that the recipient can parse it;
>     the presence in a request of a Range header with multiple byte-range
>     specifiers implies that the client can parse multipart/byteranges
>     responses.

In your case, Firefoxapparently sent "Range header with multiple byte-range".
> Range: bytes=549534-553629,549534-549535".
Main culprit of crash is possibly Firefox, when comment #6 case, to which the NSPR log was attached.
(In reply to comment #47)
> NSPR log (all:5) with local PDF in safe-mode
> new NSPR log (all:5), this time with Fx in safe-mode while loading a PDF from my harddrive

Following is a part of logs at bottom part of your log with local PDF. 
"SOMETHING STOPS FOR TOPMOST DOCUMENT" is seen in previous log with "Content-Type: multipart/byteranges" too.
This is possibly real main culprit of all your crash with PDF.

> 00000856	3.15878940	[7644] 0[128140]: DOCUMENT 1f4e800 StartDocumentLoad file:///C:/Users/mahowi/Downloads/FBF-Provisioning.pdf	
> 00000857	3.15885544	[7644] 0[128140]: DOCUMENT 1f4e800 ResetToURI file:///C:/Users/mahowi/Downloads/FBF-Provisioning.pdf	
> 00000858	3.15986156	[7644] 0[128140]: DOCSHELL 232b9a0 SetCurrentURI file:///C:/Users/mahowi/Downloads/FBF-Provisioning.pdf	
> 00000859	3.16075397	[7644] 0[128140]: DOMWINDOW 23e7160 created outer=23e6940	
> 00000860	3.16129065	[7644] 0[128140]: DOMWINDOW 23e7160 SetNewDocument file:///C:/Users/mahowi/Downloads/FBF-Provisioning.pdf	
>(snip)
> 00000880	3.50183582	[7644] 0[128140]: nsPluginHostImpl::InstantiateFullPagePlugin End mime=application/pdf, rv=0, owner=1f29500, url=file:///C:/Users/mahowi/Downloads/FBF-Provisioning.pdf
>(snip)
> 00000890	3.50598383	[7644] 0[128140]: SecureUI:4a1aa60: OnStateChange: SOMETHING STOPS FOR TOPMOST DOCUMENT

(Off-Topic)
Thanks for NSPR log with DebugView. (log number/timestamp helps us very much)
Without it, it's impossible for me to say which log lines in huge log data.
And, sorry for delay of my log check.(I hesitated till today because "all:5" :-) )

To Manfred H. Winter(bug opener):
  
You said following in your comment #23.
> "Allow fast web view" and "Allow speculative downloading in the background" are
> both checked and no crashes on this computer.
What is difference between the "this computer" in comment #23 and your PC you could/can see Crash with any PDF even with local PDF, with Adobe Reader 9.0.0?
(In reply to comment #51)
> You said following in your comment #23.
> > "Allow fast web view" and "Allow speculative downloading in the background" are
> > both checked and no crashes on this computer.
> What is difference between the "this computer" in comment #23 and your PC you
> could/can see Crash with any PDF even with local PDF, with Adobe Reader 9.0.0?
> 

The PC which is NOT crashing is the one at work, it runs Windows XP Prof. SP3, Firefox 3.0.1 (release version) and Adobe Reader 9.0.0 on some Intel Dual Core AFAIR.

The one WITH the crashes is my laptop at home running Vista32 SP1, Fx 3.0.x nightlies and Adobe Reader 9.0.0 on an Athlon Turion64 X2.

The main difference is the OS: Vista = crash, XP = no crash.
OT:
Sorry for the long NSPR logs with all:5, but that's the only variable for NSPR_LOG_MODULES I know. ;-)
Where can I find the module names for logging?
"SOMETHING STOPS FOR TOPMOST DOCUMENT" is issued at here.
> http://mxr.mozilla.org/mozilla-central/source/security/manager/boot/src/nsSecureBrowserUIImpl.cpp#805
This line was seen also in log of "My Win-XP/Fx trunk/local PDF/No crash".

By the way, I don't know parameter other than "all:5" which is adequate for problem analysis of this bug's case. I was simply convinced "very very huge log data from start of fx to end" when "all:5" came into my sight :-)
(In reply to comment #47)
> new NSPR log (all:5), this time with Fx in safe-mode while loading a PDF from my harddrive

Is this last log Fx wrote before crash? Fx crashed just after this log?
Get log with "all:5" on Win-XP(no crash), and check Fx's activity around/after end of PDF load. Can you find difference which may cause PDF pluin's crash?
Following is my log(no crash).
> [660] 0[72b140]: nsPluginHostImpl::GetPluginFactory Begin mime=application/pdf, plugin=C:\Program Files\Adobe\Reader 9.0\Reader\browser\nppdf32.dll
PDF plugin is loaded from Adobe Reader's library by plugin search.

Your log(local PDF case, with Fx 3.0.2Pre).
> 00000873 3.17666936 [7644] 0[128140]: nsPluginHostImpl::GetPluginFactory Begin mime=application/pdf, plugin=C:\Program Files\Gran Paradiso\plugins\nppdf32.dll	
> 00000874 3.18177390 [7644] 0[128140]: Loaded library C:\Program Files\Gran Paradiso\plugins\nppdf32.dll (load lib)	

You said next in Comment #3.
> Plugin nppdf32.dll gets loaded from C:\Program Files\Adobe\Reader
9.0\Reader\Browser
On which system did you check library location of PDF plugin upon Comment #3?
"C:\Program Files\Gran Paradiso\plugins\nppdf32.dll" on Vista is plugin of Adobe Reader 9.0.0? 
(In reply to comment #55)
> (In reply to comment #47)
> > new NSPR log (all:5), this time with Fx in safe-mode while loading a PDF from my harddrive
> 
> Is this last log Fx wrote before crash? Fx crashed just after this log?

Yes, it's the last log before crash. Fx crashed and Crash Reporter was displayed.

> Get log with "all:5" on Win-XP(no crash), and check Fx's activity around/after
> end of PDF load. Can you find difference which may cause PDF pluin's crash?
> 
Okay, I'll see if I can do a log tomorrow at work.


(In reply to comment #56)
> Your log(local PDF case, with Fx 3.0.2Pre).
> > 00000873 3.17666936 [7644] 0[128140]: nsPluginHostImpl::GetPluginFactory Begin mime=application/pdf, plugin=C:\Program Files\Gran Paradiso\plugins\nppdf32.dll	
> > 00000874 3.18177390 [7644] 0[128140]: Loaded library C:\Program Files\Gran Paradiso\plugins\nppdf32.dll (load lib)	
> 
> You said next in Comment #3.
> > Plugin nppdf32.dll gets loaded from C:\Program Files\Adobe\Reader
> 9.0\Reader\Browser
> On which system did you check library location of PDF plugin upon Comment #3?
> "C:\Program Files\Gran Paradiso\plugins\nppdf32.dll" on Vista is plugin of
> Adobe Reader 9.0.0? 
> 

Sorry, I didn't see that I've copied the plugin to Fx's plugin path. I've deleted it now. It has been the plugin of Adobe Reader 9.0.0. And there's no difference if it's loaded from C:\Program Files\Adobe\Reader 9.0\Reader\browser\nppdf32.dll.
Following lines are seen in log.
> 00000565 2.69056296 [7644] 0[128140]: LoadCachedPluginsInfo : Loading Cached plugininfo for C:\Program Files\Gran Paradiso\plugins\nppdf32.dll
> 00000568 2.69082999 [7644] 0[128140]: LoadCachedPluginsInfo : Loading Cached plugininfo for C:\Program Files\Adobe\Reader 9.0\Reader\browser\nppdf32.dll
> 00000571 2.69110870 [7644] 0[128140]: LoadCachedPluginsInfo : Loading Cached plugininfo for C:\Program Files\Adobe\Reader 8.0\Reader\browser\nppdf32.dll

Does "...\Adobe\Reader 8.0\Reader\..." really exists? Or merely garbage in Windows registry?
If exists, which AcroRd32.exe is invoked by nppdf32.dll of Adobe Reader 9.0.0?
 (A) Check with "Display PDF in Browser"=Off.
 (A-1) Stand alone Adobe Reader 8 : "Display PDF in Browser"=Off <= change
       Stand alone Adobe Reader 9 : "Display PDF in Browser"=On
 (A-2) Stand alone Adobe Reader 8 : "Display PDF in Browser"=On
       Stand alone Adobe Reader 9 : "Display PDF in Browser"=Off <= change
  What does Help of independent Adobe Reader window say about version?
 (B) Check with no Adobe Reader 8 condition
     Rename "...\Adobe\Reader 8.0" to "...\Adobe\Reader 8.0XXX"
Also getting Firefox crash when clicking on a link to a .pdf file.

Will not crash I right click and have it open in a new tab.

Adobe 9.

Firefox 3.0.1.


Vista w/ SP.
(In reply to comment #58)
> Following lines are seen in log.
> > 00000565 2.69056296 [7644] 0[128140]: LoadCachedPluginsInfo : Loading Cached plugininfo for C:\Program Files\Gran Paradiso\plugins\nppdf32.dll
> > 00000568 2.69082999 [7644] 0[128140]: LoadCachedPluginsInfo : Loading Cached plugininfo for C:\Program Files\Adobe\Reader 9.0\Reader\browser\nppdf32.dll
> > 00000571 2.69110870 [7644] 0[128140]: LoadCachedPluginsInfo : Loading Cached plugininfo for C:\Program Files\Adobe\Reader 8.0\Reader\browser\nppdf32.dll
> 
> Does "...\Adobe\Reader 8.0\Reader\..." really exists? Or merely garbage in
> Windows registry?

"C:\Program Files\Adobe\Reader 8.0\Reader" is an empty directory, there's no plugin in this directory. Plugin exists only in "C:\Program Files\Adobe\Reader 9.0\Reader\browser\nppdf32.dll".

Where does Fx cache the plugininfo?
(In reply to comment #61)
> Where does Fx cache the plugininfo?

Log of "...\Reader 8.0\..." is probably a plugin search result for windows registry, instead of log for loading of found plugin module.
Some entries for "Adobe Reader 8.0" remains even after uninstall. This is true too when Fx, Tb.

Now it's clear that no simple environmental problem exists in Adobe Reader.
Is there any difference between "Left click of link to PDF" and "Right click+Open in new tab"? (Since log for load of the PDF looks to be the first log for page load in your log, I guess you loaded the PDF from bookmark or via URL typed-in/pasted-to URLbar)

My questions about your problem. (Simply questions. No need to test or check.)

Why you only can experience crash with any PDF(even with local ODF) with any operation? (Your are the only one who uses "Vista SP1+Adobe Reader 9.0.0+Fx 3.0.2Pre" on the earth?)
Power management feature of Turion64 X2(hardware level) has relation?
Issue of Vista on Turion64 X2 is involved? (newest driver is supplied by AMD or PC vender? newest Hotfix is supplied by MS?)
Issue of Vista with Rageon(ATI)/GeForce(Nvidia) is involved? (newest driver is supplied by chip/card vender or PC vender?)
Vista unique feature(UAC, Fast load, ...) has relation?
Attached file NSPR log without crash on XP SP3 (obsolete) — 
(In reply to comment #55)
> (In reply to comment #47)
> > new NSPR log (all:5), this time with Fx in safe-mode while loading a PDF from my harddrive
> 
> Is this last log Fx wrote before crash? Fx crashed just after this log?
> Get log with "all:5" on Win-XP(no crash), and check Fx's activity around/after
> end of PDF load. Can you find difference which may cause PDF pluin's crash?
> 
This is a log of loading a local PDF with Fx 3.0.1 on XP SP3 without crash.
(In reply to comment #63)
> This is a log of loading a local PDF with Fx 3.0.1 on XP SP3 without crash.

Following log is seen again.
> 00000639 1.00362277 [2376] 0[328140]: nsPluginHostImpl::GetPluginFactory Begin mime=application/pdf, plugin=C:\Programme\Mozilla Firefox\plugins\nppdf32.dll
> 00000640 1.00389004 [2376] 0[328140]: Loaded library C:\Programme\Mozilla Firefox\plugins\nppdf32.dll (load lib)

"C:\Programme\Mozilla Firefox\plugins\nppdf32.dll" on XP is PDF plugin of Adobe Reader 9.0.0? 
Question again.
You said next in Comment #3.
> Plugin nppdf32.dll gets loaded from C:\Program Files\Adobe\Reader 9.0\Reader\Browser
On which system did you check library location of PDF plugin upon Comment #3?
Who installed nppdf32.dll in your Fx's plugins directory?

I'm confident that you didn't produce any misconfiguration relates to AcroRd32.exe & nppdf32.dll. However, NSPR log won't provide any data about nppdf32.dll's version. Please remove nppdf32.dll from Fx's plugins directory before getting log.

Log of no Crash (XP, Fx 3.0.1, Local PDF)
> [2376] 0[328140]:  - Using Tahoma
Log of Crash(Vista, Fx 3.0.2Pre, Local PDF).
> [7644] 0[128140]:  - Using Segoe UI

Segoe UI is clear type font.
> http://en.wikipedia.org/wiki/Segoe_UI#Segoe_UI
Font related issue with Adobe's PDF plugin on Vista? (this is also a "Vista unique".)
MSDN says; 
> http://msdn.microsoft.com/en-us/library/aa511295.aspx
> Segoe UI is less readable without ClearType enabled.
Do you enable clear type? Or disable it?
If enabled or disabled is swapped, crash disappears?
(In reply to comment #64)
> "C:\Programme\Mozilla Firefox\plugins\nppdf32.dll" on XP is PDF plugin of Adobe
> Reader 9.0.0? 

Yes.

> Question again.
> You said next in Comment #3.
> > Plugin nppdf32.dll gets loaded from C:\Program Files\Adobe\Reader 9.0\Reader\Browser
> On which system did you check library location of PDF plugin upon Comment #3?

This was on my system at home with Vista. Although there was a copy of nppdf32.dll in Fx's plugin directory, it has been the nppdf32.dll of Adobe Reader 9.0.0.

> Who installed nppdf32.dll in your Fx's plugins directory?
> 

I don't remember copying nppdf32.dll to Fx's plugin directory, so I think it gets installed there by Adobe Reader.

> I'm confident that you didn't produce any misconfiguration relates to
> AcroRd32.exe & nppdf32.dll. However, NSPR log won't provide any data about
> nppdf32.dll's version. Please remove nppdf32.dll from Fx's plugins directory
> before getting log.
> 

Okay, I deleted nppdf32.dll now from Fx's plugin directory and did a new log.
Attachment #334229 - Attachment is obsolete: true
(In reply to comment #66)
> MSDN says; 
> > http://msdn.microsoft.com/en-us/library/aa511295.aspx
> > Segoe UI is less readable without ClearType enabled.
> Do you enable clear type? Or disable it?
> If enabled or disabled is swapped, crash disappears?
> 

AFAIK, ClearType is enabled on my Vista PC as well as on the PC using XP. I'll check that this afternoon when I'm at home.

(In reply to comment #65)
> Log of no Crash (XP, Fx 3.0.1, Local PDF)
> > [2376] 0[328140]:  - Using Tahoma
> Log of Crash(Vista, Fx 3.0.2Pre, Local PDF).
> > [7644] 0[128140]:  - Using Segoe UI
> 
> Segoe UI is clear type font.
> > http://en.wikipedia.org/wiki/Segoe_UI#Segoe_UI
> Font related issue with Adobe's PDF plugin on Vista? (this is also a "Vista
> unique".)
> 

How could I check this? I don't know where I should change the font Fx or Adobe Reader uses. In Fx's properties (here @work, XP) there's no Tahoma mentioned.
I deleted some of the "Using Segoe UI" lines to get the log to less than 512kB.

(In reply to comment #62)
> Now it's clear that no simple environmental problem exists in Adobe Reader.
> Is there any difference between "Left click of link to PDF" and "Right
> click+Open in new tab"? (Since log for load of the PDF looks to be the first
> log for page load in your log, I guess you loaded the PDF from bookmark or via
> URL typed-in/pasted-to URLbar)
> 

Now I've opened a PDF in a new tab. Everything seems to work until I switch to the newly created tab. When I bring the tab with the PDF to foreground, Fx crashes. Log ends with the crash.

> My questions about your problem. (Simply questions. No need to test or check.)
> 
> Why you only can experience crash with any PDF(even with local ODF) with any
> operation? (Your are the only one who uses "Vista SP1+Adobe Reader 9.0.0+Fx
> 3.0.2Pre" on the earth?)

That's what I'm asking myself, too. ;-)

> Power management feature of Turion64 X2(hardware level) has relation?
> Issue of Vista on Turion64 X2 is involved? (newest driver is supplied by AMD or
> PC vender? newest Hotfix is supplied by MS?)

All the latest hotfixes and drivers are installed on my laptop.

> Issue of Vista with Rageon(ATI)/GeForce(Nvidia) is involved? (newest driver is
> supplied by chip/card vender or PC vender?)

I'm using driver version 7.15.11.7570 for my NVidia GeForce Go 7400.
(In reply to comment #69)
> > Font related issue with Adobe's PDF plugin on Vista? (this is also a "Vista unique".)
> How could I check this?

Oh, sorry for confusing comment. It's question to myself. I also don't know how to check it. I don't know about font related bahaivior of Adobe Reader. I can't imagine reason why UI font can cause crash of nppdf32.dll if the UI font is the cause of crash.

(In reply to comment #70)
> Now I've opened a PDF in a new tab. Everything seems to work until I switch to the newly created tab.
> When I bring the tab with the PDF to foreground, Fx crashes. Log ends with the crash.

You seem to have found entrance to labyrinth.
( Workaround of your crash: Open in background tab, and never activate it :-) )

>(Load is already completed in background tab)
>(Click tab)
> 00005558 7.25941086 [6208] 0[628140]: nsHttpHandler::NewURI
> 00005559 9.16081905 [6208] 0[628140]: nsHttpHandler::NewURI
>(Characters in font related log. 0x20 is excluded)
> http://www.barchetta-lexikon.de/?action=suche
> http://www.barchetta-lexikon.de/?action=index&daten=O
> http://www.barchetta-lexikon.de/s021_frontumbau.pdf
> (application/pdfObject)
> barchetta-Lexikon:ProjektFrontumbauvonJochenStumpf
> s021_frontumbau.pdf
> (application/pdfObject)
> http://www.barchetta-lexikon.de/pdf/s021_frontumbau.pdf
> hexjFFrontu&s021_fm.pd(l/(application
> 00006566 11.66268444 [6208] 0[628140]:  0x2026 -
> 00006567 11.66273689 [6208] 0[628140]:  - Using Segoe UI:700
> 00006568 11.66566277 [6208] 0[628140]:  Found 1 ranges
>(end of log == Crash)

Above are probably font logs for characters used in UI by Fx(window title, URL bar text, status bar text etc.), for both old tab and new tab. UI font doesn't look to have relation to crash. Crash seems to occur when nppdf32.dll tries to write rendered PDF data in window(canvas?).

Crash of nppdf32.dll when contention between UI update by Fx and PDF content display by nppdf32.dll&AcroRd32.exe?
Crash of nppdf32.dll on Vista because of intercept of event at other tab? (Bug of "mouse scroll at a tab" is executed at other tab where plugin of PDF/Flash etc. is used.)
(In reply to comment #70)
> NSPR log (all:5) loading PDF in a different tab

Following log is seen.
> 00001693 4.12012196 [6208] 0[628140]: Range: bytes=549534-553629,549534-549535
Completely same "Range: bytes=549534-553629,549534-549535" request is seen in your first log too(see Comment #45). I think this funny "Range:" doesn't have relation to this bug's issue. But it may produce other problem.
(I can't imagine environment where network error always occurs at same point. I can't guess reason why over-wrapping "549534-553629,549534-549535".)
This kind of funny phenomenon makes problem analysis difficult. Please get logs with same local PDF.

I quickly observed file I/O of firefox.exe(and acrord32.exe under fx) by Process Monitor. PDF file was read after click of background tab. All PDF file related activity was invoked after activation of the tab.
> Sysinternals Utilities Index
>  http://technet.microsoft.com/en-us/sysinternals/bb545027.aspx
> Process Monitor v1.37
>  http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

Compare log on XP and log on Vista. 
(1) Start Process Monitor. Filter : Process name is firefox.exe, include.
(2) Stop Capture
(3) Load PDF in background tab, and wat for while.
(4) Start Capture
(5) Click tab for PDF
    - Local PDF file is read (when remote PDF, copy in %temp% is read). 
    - Activities on Adobe Reader 9.0.0 library is seen.
(6) Stop Capture, and save log.

Although detailed activity is not obtained by file I/O log only, I think checking of "crash occurs on Vista when/where/at which step in log" is a good first step to understand "what happens". I think it'll help analysis of debug log too.
(In reply to comment #72)
> (In reply to comment #70)
> > NSPR log (all:5) loading PDF in a different tab
> 
> Following log is seen.
> > 00001693 4.12012196 [6208] 0[628140]: Range: bytes=549534-553629,549534-549535
> Completely same "Range: bytes=549534-553629,549534-549535" request is seen in
> your first log too(see Comment #45). I think this funny "Range:" doesn't have
> relation to this bug's issue. But it may produce other problem.
> (I can't imagine environment where network error always occurs at same point. I
> can't guess reason why over-wrapping "549534-553629,549534-549535".)
> This kind of funny phenomenon makes problem analysis difficult. Please get logs
> with same local PDF.
> 

This is reproducable. I get the same "Range:" thing every time I load this PDF:

--
00002061	3.63803434	[11344] 0[228140]: nsHttpHandler::NewChannel	
00002062	3.63807273	[11344] 0[228140]: nsHttpHandler::NewProxiedChannel [proxyInfo=0]	
00002063	3.63810825	[11344] 0[228140]: Creating nsHttpChannel @5c7ef90	
00002064	3.63814306	[11344] 0[228140]: nsHttpChannel::Init [this=5c7ef90]	
00002065	3.63818049	[11344] 0[228140]: host=www.barchetta-lexikon.de port=-1	
00002066	3.63821387	[11344] 0[228140]: uri=http://www.barchetta-lexikon.de/pdf/s021_frontumbau.pdf	
00002067	3.63824797	[11344] 0[228140]: Creating nsHttpConnectionInfo @6ac4160	
00002068	3.63830376	[11344] 0[228140]: nsHttpChannel::SetRequestHeader [this=5c7ef90 header="Range" value="bytes=549534-553629,549534-549535" merge=0]
--

But it seems not to be related to this bug. This logged while loading the PDF in a new tab, but a while before the crash. Fx crashes just when I switch to this tab.

(In reply to comment #71)
> Crash of nppdf32.dll on Vista because of intercept of event at other tab? (Bug
> of "mouse scroll at a tab" is executed at other tab where plugin of PDF/Flash
> etc. is used.)
> 
I only leftclicked on new tab to open it. No scrolling or any other event.


I'll try to get a log with ProcessMonitor tomorrow at work if I get the time to do this. Any hints what to look for as the log here on Vista is about 7.500 lines long?
I've uploaded Process Monitor logs to http://www.mahowi.de/XP-Log.csv (no crash) and http://www.mahowi.de/Vista-Log.csv (crash). Sorry, but I didn't have the time to analyze the logs. I'll try to do this this afternoon.
Mispelled the 2nd log, should be http://www.mahowi.de/Vista-Log.CSV
Logs of data write to SharedDataEvents are seen in log of XP, but not seen in log of Vista. SharedDataEvents file is next on my system(on XP), and was updated upon PDF open by Fx/Seamonkey.
> C:\Documents and Settings\wada\Application Data\Adobe\Acrobat\9.0\SharedDataEvents

Possibly sqlite.dll version related issue.
In my XP system, sqlite.dll exists in Adobe Reader 9's directory only.

(XP, no crash)
"20728","15:49:30,6223241","firefox.exe","2880","Load Image","C:\Programme\Adobe\Reader 9.0\Reader\sqlite.dll","SUCCESS","Image Base: 0x6e60000, Image Size: 0x3a000"

(Vista, crash)
> "27587","07:27:43,3913202","firefox.exe","3348","Load Image","C:\Windows\System32\sqlite.dll","SUCCESS","Image Base: 0x3a00000, Image Size: 0x42000"

Check file locations by "DIR sqlite.dll /S", and check version of sqlite.dll of Win Vista and Adobe Reader 9.
Following can be a workaround?
  - Rename C:\Windows\System32\sqlite.dll to sqlite.dll-Bakup
  - Copy sqllite.dll from Adobe Reader's directory to System32 directory
Summary: Fx crashes when displaying PDF with Adobe Reader 9.0.0 plugin [@ kernel32.dll@0x442eb - AcroRd32.dll@0xef2be] → Fx crashes when displaying PDF with Adobe Reader 9.0.0 plugin [@ kernel32.dll@0x442eb - AcroRd32.dll@0xef2be] (Vista only. nppdf32.dll crashes upon any attempt to open any PDF in tab of Firefox on Vista)
Summary: Fx crashes when displaying PDF with Adobe Reader 9.0.0 plugin [@ kernel32.dll@0x442eb - AcroRd32.dll@0xef2be] (Vista only. nppdf32.dll crashes upon any attempt to open any PDF in tab of Firefox on Vista) → Fx crashes when displaying PDF with Adobe Reader 9.0.0 plugin [@ kernel32.dll@0x442eb - AcroRd32.dll@0xef2be] (Vista only. AcroRd32.exe or nppdf32.dll crashes upon any attempt to open any PDF in tab of Firefox on Vista)
Summary: Fx crashes when displaying PDF with Adobe Reader 9.0.0 plugin [@ kernel32.dll@0x442eb - AcroRd32.dll@0xef2be] (Vista only. AcroRd32.exe or nppdf32.dll crashes upon any attempt to open any PDF in tab of Firefox on Vista) → Fx crashes when displaying PDF with Adobe Reader 9.0.0 plugin [@ kernel32.dll@0x442eb - AcroRd32.dll@0xef2be] (Vista only. AcroRd32.exe, not nppdf32.dll, crashes upon any attempt to open any PDF in tab of Firefox on Vista)
If my guess is right, I think AcroRd32.exe crashes too when "Display PDF in Browser"=Off on your Vista, because AcroRd32.exe of Adobe Reader 9.0.0 is kicked under firefox.exe by nppdf32.dll of Adobe Reader 9.0.0 under firefox.exe. Is it true? Or crash on Vista only when "Display PDF in Browser"=On?

(In reply to comment #78)
> Logs of data write to SharedDataEvents are seen in log of XP, but not seen in
> log of Vista. SharedDataEvents file is next on my system(on XP), and was
> updated upon PDF open by Fx/Seamonkey.
> > C:\Documents and Settings\wada\Application Data\Adobe\Acrobat\9.0\SharedDataEvents
> 

File exists here also, but there's no writing to it logged.

> Possibly sqlite.dll version related issue.
> In my XP system, sqlite.dll exists in Adobe Reader 9's directory only.
> 
> (XP, no crash)
> "20728","15:49:30,6223241","firefox.exe","2880","Load
> Image","C:\Programme\Adobe\Reader 9.0\Reader\sqlite.dll","SUCCESS","Image Base:
> 0x6e60000, Image Size: 0x3a000"
> 
> (Vista, crash)
> > "27587","07:27:43,3913202","firefox.exe","3348","Load Image","C:\Windows\System32\sqlite.dll","SUCCESS","Image Base: 0x3a00000, Image Size: 0x42000"
> 
> Check file locations by "DIR sqlite.dll /S", and check version of sqlite.dll of
> Win Vista and Adobe Reader 9.
> Following can be a workaround?
>   - Rename C:\Windows\System32\sqlite.dll to sqlite.dll-Bakup
>   - Copy sqllite.dll from Adobe Reader's directory to System32 directory
> 

C:\Windows\System32\sqlite.dll: version 2.18.14.0, 15.11.2006
C:\Program Files\Adobe\Reader 9.0\Reader\sqlite.dll: version 9.0.0.1, 12.06.2008

I renamed the sqlite.dll in System32 to sqlite.bak. Now Fx crashes immediately when PDF gets loaded in background tab, BEFORE I switch to the new tab. Same result even when I copy Adobe's sqlite.dll to System32 or copy the old dll back.
I did a new NSPR log when there was only a sqlite.dll in Adobe directory. I also logged this crash with Process Monitor: http://www.mahowi.de/Vista-Log2.csv
There's no "Load Image" line about sqlite.dll anymore in the log.

(In reply to comment #79)
> If my guess is right, I think AcroRd32.exe crashes too when "Display PDF in
> Browser"=Off on your Vista, because AcroRd32.exe of Adobe Reader 9.0.0 is
> kicked under firefox.exe by nppdf32.dll of Adobe Reader 9.0.0 under
> firefox.exe. Is it true? Or crash on Vista only when "Display PDF in
> Browser"=On?
> 

You're right, crash appears even when "Display PDF in Browser"=Off.
(In reply to comment #80)
> There's no "Load Image" line about sqlite.dll anymore in the log.

Crash seems to have occurred before load of sqlite.dll to write dat in SharedDataEvents. (crash => write task of SharedDataEvents is not sceduled or killed. i.e. write task of SharedDataEvents is victim)

> C:\Windows\System32\sqlite.dll: version 2.18.14.0, 15.11.2006
> C:\Program Files\Adobe\Reader 9.0\Reader\sqlite.dll: version 9.0.0.1, 12.06.2008

Who installed sqlite.dll in System32?
Why such very old version on newest Vista? 
Is it possible to cleanly uninstall SQLite(and re-install if required) from your Vista? (to make problem simple. to exclude problem due to old SQLite case)

> You're right, crash appears even when "Display PDF in Browser"=Off.

I was convinced that no problem with "Display PDF in Browser"=Off in your Vista case too...
When crashed? Before background tab click? Or after background tab click? After PDF window open & PDF display? Or no PDF window? 
Can you test and get data with "Display PDF in Browser"=Off? (near to "minimum case" than "Display PDF in Browser"=On)
(In reply to comment #81)
> (In reply to comment #80)
> > C:\Windows\System32\sqlite.dll: version 2.18.14.0, 15.11.2006
> > C:\Program Files\Adobe\Reader 9.0\Reader\sqlite.dll: version 9.0.0.1, 12.06.2008
> 
> Who installed sqlite.dll in System32?
> Why such very old version on newest Vista? 
> Is it possible to cleanly uninstall SQLite(and re-install if required) from
> your Vista? (to make problem simple. to exclude problem due to old SQLite case)

I don't know which app installed old version of sqlite in System32. The only sqlite.dll I found in the registry is the one from Adobe. I wish there were a packet manager such as rpm on linux.
As there's no reference to this dll in the registry, I'll simply remove it from system32.

> 
> > You're right, crash appears even when "Display PDF in Browser"=Off.
> 
> I was convinced that no problem with "Display PDF in Browser"=Off in your Vista
> case too...
> When crashed? Before background tab click? Or after background tab click? After
> PDF window open & PDF display? Or no PDF window? 
> Can you test and get data with "Display PDF in Browser"=Off? (near to "minimum
> case" than "Display PDF in Browser"=On)
> 

Okay, I'll do a new log with "Display PDF in Browser"=Off.
http://www.mahowi.de/Logfile.CSV is a log with Process Monitor with "Display PDF in Browser"=Off. But I can't see any difference to the log before at first sight.
Fx crashes when PDF gets opened. No PDF window appears.
It works!

After deleting the old sqlite.dll, Fx worked again with a new profile. But it still crashed with my default one. So I uninstalled all extensions, but Fx still crashed. To recheck if it's a problem with an extension, I installed the same addons in the new profile. No crash.
So I deleted my user.js and Firefox works again. Unfortunately I deleted my backup of the problematic user.js by accident, so I can't tell which entry leaded to the crash. I'll search my backups for the old user.js to check for the problematic entry.

But the old sqlite.dll was defintely one reason for crashes. Even with a new profile Fx crashed if I had it in System32.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Of course I meant prefs.js, not user.js.
Very strange, but the pref that caused the crash was:
> user_pref("general.useragent.extra.microsoftdotnet", "(.NET CLR 3.5.30729)");

There have been two "general.useragent.extra." lines in prefs.js. So it seems to lead to a crash with Adobe Reader when there is more than one extra useragent header.

But this second line has been installed just yesterday because of an .NET 3.5 update.

So the crashes because of which I opened this bug were a result of the old sqlite.dll in System32.

The reason for the last crashes when PDF window didn't appear and Fx immediately crashed while opening a PDF was the second extra useragent header.
So could this be a kind of buffer overflow with too long useragent strings?
(In reply to comment #85)
> After deleting the old sqlite.dll, Fx worked again with a new profile.
> But it still crashed with my default one.

(In reply to comment #87)
> the pref that caused the crash was:
> > user_pref("general.useragent.extra.microsoftdotnet", "(.NET CLR 3.5.30729)");

You seem to have discovered exit from labyrinth at last.

I also think there are two different crashes.
(A) Crash of AcroRd32.exe due to old sqlite.dll (crash even with new profile)
(B) New crash of external program (probably crash in nppdf32.dll)
    when user agent string is modified or two "general.useragent.extra." lines.
    (Possibly PDF plugin version of Bug 83376 for Java plugin)
I think crash Reporter's stack trace says "crash in acrord32.exe" (Comment #33 say so) for (A) and "crash in nppdf32.dll" for (B). Is it right?

(A) is new with Adobe Reader 9.0.0.
  - Till Adobe Reader 8, Acrord32.exe is invoked as independent process.
    So sqlite.dll was loaded from Adobe Reader's library till Adobe Reader 8.
If crash of Adobe Reader 9 occurs when next test, we can surely say "old sqlite.dll is the only one culprit".
  1. Rename sqlite.dll in Adobe Reader 9's library to sqlite.dll-Bkup 
  2. Copy old sqllite.dll from System32 to Adobe Reader 9's library
  3. Delete(after backup) sqlite.dll from System32 direcotory.
  4. Open PDF at standalone Adobe Reader 9.0.0.
If next is workaround of crash by old sqlite.dll when "Display PDF in Browser="Off, we probably can say a small fault by Adobe exists.
  1. Put old sqlite.dll in System 32 directory
  2. "Display PDF in Browser" = Off
  3. Rename ...\Reader\Browser\nppdf32.dll to nppdf32.dll-Bkup
  4. Open PDF by Fx  
  I guess as follows.
    Fx searches nppdf32.dll but not found, and "Helper Application" is used, and
    standalone Adobe Reader 9.0.0 is kicked. Thus no crash by old sqlite.dll.

For problem of (B).

(First NSPR log in Commment #6)
> 00000944b 2.74564052b [13984] 0[928140]: Loaded library C:\Program Files\Gran Paradiso\plugins\nppdf32.dll (load lib)
> 00000945b 2.99184847b [13984] 0[928140]: nsPluginHostImpl::UserAgent return=Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.2pre) Gecko/2008073106 GranParadiso/3.0.2pre Mnenhy/0.7.5.20005
> 00000946b 2.99203920b [13984] 0[928140]: nsPluginHostImpl::UserAgent return=Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.2pre) Gecko/2008073106 GranParadiso/3.0.2pre Mnenhy/0.7.5.20005
> 00000947b 3.01673484b [13984] 0[928140]: nsPluginHostImpl::UserAgent return=Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.2pre) Gecko/2008073106 GranParadiso/3.0.2pre Mnenhy/0.7.5.20005
> 00000948b 3.01736999b [13984] 0[928140]: nsPluginHostImpl::TrySetupPluginInstance Finished mime=application/pdf, rv=0, owner=6f06500, url=http://www.barchetta-lexikon.de/pdf/s021_frontumbau.pdf
> 00000949b 3.02023721b [13984] 0[928140]: nsPluginStreamListenerPeer::InitializeFullPage instance=5a2b980
> 00000950b 3.02077007b [13984] 0[928140]: nsPluginHostImpl::InstantiateFullPagePlugin End mime=application/pdf, rv=0, owner=6f06500, url=http://www.barchetta-lexikon.de/pdf/s021_frontumbau.pdf
> 00000953b 3.02423549b [13984] 0[928140]: nsPluginHostImpl::UserAgent return=Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.2pre) Gecko/2008073106 GranParadiso/3.0.2pre Mnenhy/0.7.5.20005

(NSPR log in Commment #83)
> 00000795 2.29245329 [10884] 0[128140]: nsPluginHostImpl::UserAgent return=(null)
> 00000796 2.29597259 [10884] 0[128140]: nsPluginHostImpl::UserAgent return=(null)

This (null) perhaps is cause of new crash in nppdf32.dll.
(B) possibly occurs with any of Fx 3.0.1, Fx 3.0.2Pre, and Fx latest-trunk.
(B) is apparently different from problem of (A).
Please open new bug for problem of (B).

WORKSFORME at bugzilla.mozilla.org never means "problem varnished at you environment by some workarounds".
This bug should be for problem (A) only, and should be closed as INVALID later, not as WORKSFORME. I believe Adobe's lack of care for "there can be sqlite.dll which is already installed in system" is involved in the problem. Because no Fx's fault is involved, this bug should be closed as INVALID, but we have to analyze "what is Adobe's fault" before close as INVALID.
Re-opening.

By the way, I believe you are the only one in the earth who has both of (A) & (B) at same time :-)
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Confirming based on logs provided by bug opener.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Fx crashes when displaying PDF with Adobe Reader 9.0.0 plugin [@ kernel32.dll@0x442eb - AcroRd32.dll@0xef2be] (Vista only. AcroRd32.exe, not nppdf32.dll, crashes upon any attempt to open any PDF in tab of Firefox on Vista) → Fx crashes when displaying PDF with Adobe Reader 9.0.0[@ kernel32.dll@0x442eb - AcroRd32.dll@0xef2be] (AcroRd32.exe invoked under firefox.exe process always crashes, if old sqlite.dll exists in System32 directory)
I made the test for (A):
- Adobe Reader crashes with old sqlite.dll in it's own directory.
- When I open a PDF from Fx with old sqlite.dll in System32 and no nppdf32.dll,
  Adobe Reader starts and crashes! And Fx also crashes with
  Crash ID: bp-ece4ff0a-7135-11dd-ada4-001a4bd43ef6
  So Adobe Reader seems to use sqlite.dll in System32 if started from another
  application.

I'll open a new bug for (B) tomorrow.
(In reply to comment #90)
> So Adobe Reader seems to use sqlite.dll in System32 if started from another application.

Following is log lines for loading of sqlite.dll in you log data on XP.
"At where sqlite.dll is found" depends on search order of library.
I think following is a workaround of your case(old sqlite/dll in System32).
  ...\system32\sqlite.dll = old version
  ...\Reader\sqlite.dll   = new version
  At Command Prompt
   0. PATH
   1. CD "C:\Program Files\Adobe\Reader 9.0\Reader
   2. start <program_library_of_firefox>\firefox.exe
  Since current directory is ...\Reader, sqlite.dll is loaded from it.
   
>(Looks to be first search process)
>(Current directory of process of Firefox.exe)
> "20561","15:49:30,5838083", (snip) ,"QueryOpen" ,"C:\Programme\Mozilla Firefox\sqlite.dll","NAME NOT FOUND",""
>(Search order specified in PATH)
> "20562","15:49:30,5841942", (snip) ,"QueryOpen" ,"C:\WINDOWS\system32\sqlite.dll","NAME NOT FOUND",""
> "20563","15:49:30,5845752", (snip) ,"QueryOpen" ,"C:\WINDOWS\system\sqlite.dll","NAME NOT FOUND",""
> "20564","15:49:30,5848624", (snip) ,"QueryOpen" ,"C:\WINDOWS\sqlite.dll","NAME NOT FOUND",""
>(Perhaps search of library from which Firefox.exe/AcroRd32.exe is loaded)
> "20565","15:49:30,5850866", (snip) ,"QueryOpen" ,"C:\Programme\Mozilla Firefox\sqlite.dll","NAME NOT FOUND",""
> "20566","15:49:30,5857346", (snip) ,"QueryOpen" ,"C:\Programme\Adobe\Reader 9.0\Reader\plug_ins\sqlite.dll","NAME NOT FOUND",""
> "20567","15:49:30,5862037", (snip) ,"QueryOpen" ,"C:\Programme\Adobe\Reader 9.0\Reader\sqlite.dll","SUCCESS","CreationTime: 12.06.2008 00:00:38, LastAccessTime: 20.08.2008 15:39:03, LastWriteTime: 12.06.2008 00:00:38, ChangeTime: 02.07.2008 16:34:20, AllocationSize: 237.568, EndOfFile: 237.568, FileAttributes: A"

>(Looks to be second search process)
>(Current directory of Firefox.exe)
> "20568","15:49:30,5864152", (snip) ,"QueryOpen" ,"C:\Programme\Mozilla Firefox\sqlite.dll","NAME NOT FOUND",""
>(Search order specified in PATH)
> "20569","15:49:30,5867931", (snip) ,"QueryOpen" ,"C:\WINDOWS\system32\sqlite.dll","NAME NOT FOUND",""
> "20570","15:49:30,5871950", (snip) ,"QueryOpen" ,"C:\WINDOWS\system\sqlite.dll","NAME NOT FOUND",""
> "20571","15:49:30,5874755", (snip) ,"QueryOpen" ,"C:\WINDOWS\sqlite.dll","NAME NOT FOUND",""
>(Perhaps search of library from which Firefox.exe/AcroRd32.exe is loaded)
> "20572","15:49:30,5876983", (snip) ,"QueryOpen" ,"C:\Programme\Mozilla Firefox\sqlite.dll","NAME NOT FOUND",""
> "20573","15:49:30,5882474", (snip) ,"QueryOpen" ,"C:\Programme\Adobe\Reader 9.0\Reader\plug_ins\sqlite.dll","NAME NOT FOUND",""
> "20574","15:49:30,5887503", (snip) ,"QueryOpen" ,"C:\Programme\Adobe\Reader 9.0\Reader\sqlite.dll","SUCCESS","CreationTime: 12.06.2008 00:00:38, LastAccessTime: 20.08.2008 15:39:03, LastWriteTime: 12.06.2008 00:00:38, ChangeTime: 02.07.2008 16:34:20, AllocationSize: 237.568, EndOfFile: 237.568, FileAttributes: A"
> "20575","15:49:30,5892090", (snip) ,"CreateFile","C:\Programme\Adobe\Reader 9.0\Reader\sqlite.dll","SUCCESS","Desired Access: Execute/Traverse, Synchronize, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Delete, AllocationSize: n/a, OpenResult: Opened"
> "20725","15:49:30,6220300", (snip) ,"CloseFile" ,"C:\Programme\Adobe\Reader 9.0\Reader\sqlite.dll","SUCCESS",""
> "20728","15:49:30,6223241", (snip) ,"Load Image","C:\Programme\Adobe\Reader 9.0\Reader\sqlite.dll","SUCCESS","Image Base: 0x6e60000, Image Size: 0x3a000"

If Mozilla Company decided to invoke acrord32.exe under firefox.exe process, Mozilla Company should care for "order of module search".
If Adobe decided to invoke acrord32.exe under firefox.exe process, Adobe should care for "order of module search".

I opened bug 451944 for (B).
(In reply to comment #90)
> - When I open a PDF from Fx with old sqlite.dll in System32 and no nppdf32.dll,
>   Adobe Reader starts and crashes! And Fx also crashes with
>   Crash ID: bp-ece4ff0a-7135-11dd-ada4-001a4bd43ef6
>   So Adobe Reader seems to use sqlite.dll in System32 if started from another
>   application.
> 
Sorry, I've forgotten to rename nppdf32.dll in Adobe's dir. So acrord32.exe (external) got started by nppdf32.dll.
If there's no nppdf32.dll found by Fx, external Adobe Reader gets started and no crash appears.

BTW, nppdf32.dll gets installed by Adobe Reader in Fx's plugin directory and in it's own directory.
(In reply to comment #91)
> (In reply to comment #90)
> > So Adobe Reader seems to use sqlite.dll in System32 if started from another application.
> 
> Following is log lines for loading of sqlite.dll in you log data on XP.
> "At where sqlite.dll is found" depends on search order of library.
> I think following is a workaround of your case(old sqlite/dll in System32).
>   ...\system32\sqlite.dll = old version
>   ...\Reader\sqlite.dll   = new version
>   At Command Prompt
>    0. PATH
>    1. CD "C:\Program Files\Adobe\Reader 9.0\Reader
>    2. start <program_library_of_firefox>\firefox.exe
>   Since current directory is ...\Reader, sqlite.dll is loaded from it.
> 

No, this doesn't work either. I started Firefox with:
> C:\Program Files\Adobe\Reader 9.0\Reader>"\Program Files\Gran Paradiso\firefox.exe" -p
But it crashes with:
Crash ID: bp-84f0264a-7264-11dd-a947-001a4bd43ef6


    
    

    
  
Process Monitor log for comment #95 at http://www.mahowi.de/log20080825.csv

> "30697","07:30:28,6812087","firefox.exe","20100","QueryOpen","C:\Program Files\Gran Paradiso\sqlite.dll","FAST IO DISALLOWED",""
> "30698","07:30:28,6813289","firefox.exe","20100","CreateFile","C:\Program Files\Gran Paradiso\sqlite.dll","NAME NOT FOUND","Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a"
> "30699","07:30:28,6815985","firefox.exe","20100","QueryOpen","C:\Windows\System32\sqlite.dll","FAST IO DISALLOWED",""
> "30700","07:30:28,6817331","firefox.exe","20100","CreateFile","C:\Windows\System32\sqlite.dll","SUCCESS","Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened"
> "30701","07:30:28,6819868","firefox.exe","20100","QueryStandardInformationFile","C:\Windows\System32\sqlite.dll","SUCCESS","AllocationSize: 262.144, EndOfFile: 262.144, NumberOfLinks: 1, DeletePending: False, Directory: False"
> "30702","07:30:28,6820256","firefox.exe","20100","QueryBasicInformationFile","C:\Windows\System32\sqlite.dll","SUCCESS","CreationTime: 25.08.2008 07:10:51, LastAccessTime: 25.08.2008 07:23:28, LastWriteTime: 15.11.2006 11:26:52, ChangeTime: 25.08.2008 07:10:59, FileAttributes: A"
> "30703","07:30:28,6820399","firefox.exe","20100","CloseFile","C:\Windows\System32\sqlite.dll","SUCCESS",""
> "30706","07:30:28,6822642","firefox.exe","20100","CreateFile","C:\Windows\System32\sqlite.dll","SUCCESS","Desired Access: Read Data/List Directory, Execute/Traverse, Synchronize, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Delete, AllocationSize: n/a, OpenResult: Opened"
> "30714","07:30:28,6825885","firefox.exe","20100","CloseFile","C:\Windows\System32\sqlite.dll","SUCCESS",""
> "30717","07:30:28,6830769","firefox.exe","20100","Load Image","C:\Windows\System32\sqlite.dll","SUCCESS","Image Base: 0x4370000, Image Size: 0x42000"

Although I started Firefox from within "C:\Program Files\Adobe\Reader 9.0\Reader" sqlite.dll gets searched in Firefox's path and system path.

    
    

    
  
(In reply to comment #97)
> Although I started Firefox from within "C:\Program Files\Adobe\Reader
> 9.0\Reader" sqlite.dll gets searched in Firefox's path and system path.

I got same result as yours except crash on XP. PATH environment variable/Current directory doesn't seem to have relation to "search order". Sorry for my wrong guess.

    
    

    
  
AFAIK search order should be current directory, program's directory, %PATH%.
Is there any way to check if it's Fx or Adobe Reader which uses the wrong search order?

    
    

    
  
(In reply to comment #99)
> AFAIK search order should be current directory, program's directory, %PATH%.

I also thought so when I posted wrong comment which forced you needless test.
But it seems to be wrong.

Following is my PATH setting.
> PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\wada\$BIN\PHP;
C:\wada\$BIN\dig;C:\wada\$BIN;C:\Program Files\ooRexx;C:\Program Files\Common Files\GTK\2.0\bin;C:\wada\REXX;C:\Program Files\QuickTime\QTSystem\

> (Set by MS Win-XP since initial)
>  C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;
> (By installer of Object REXX)
>  C:\Program Files\ooRexx;
> (By installer of GTK 2, which is required for GIMP)
>  C:\Program Files\Common Files\GTK\2.0\bin;
> (By installer of Quick Time)
>  C:\Program Files\QuickTime\QTSystem\
> (Others are set by myself manualy)
And PATH doesn't have ".;" as first string on my MS Win XP.

My quick test result.
(A) "C:\WINDOWS\system32, C:\WINDOWS\system, C:\WINDOWS" was search order
    for sqlite.dll, and any other library in PATH was not searched,
    including C:\WINDOWS\System32\Wbem which is set by MS Win-XP.
(B) I added ".;"(current directory) to PATH, but search order for sqlite.dll
    was same as (A).

DLL related design is changed very much from MS DOS/Win 3/Win 95. And it seems to depends on design of application(Use old PATH environment variable or not).

> Is there any way to check if it's Fx or Adobe Reader which uses the wron
g search order?

I can't consider it "wrong order". I think the order is based on modern MS Win's DLL related design or modern MS Win's standard.

    
    

    
  
My path:
> PATH=C:\Program Files\PC Connectivity Solution\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Program Files\GNU\GnuPG\pub;C:\Program Files\QuickTime\QTSystem\;C:\Program Files\PC Connectivity Solution\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Program Files\GNU\GnuPG\pub;C:\Users\mahowi\Program Files\wget;C:\Program Files\Common Files\Nero\Lib\

Search order for dlls on Win32 is explained here: http://msdn.microsoft.com/en-us/library/ms682586.aspx

> If SafeDllSearchMode is enabled, the search order is as follows:
> 
>    1. The directory from which the application loaded.
>    2. The system directory. Use the GetSystemDirectory function to get the path of this directory.
>    3. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
>    4. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
>    5. The current directory.
>    6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.

SafeDllSearchMode is enabled by default since XP SP2.

According to this search order, Adobe Reader seems to be started by Firefox. Therefor search order is:
(1) Fx dir
(2) %WINDIR%\system32
(3) %WINDIR%\system
(4) %WINDIR%
(5) .
(6) %PATH%

Because Acrobat Reader until version 8 was started as an independent process, (1) was Adobe's dir. Now with Adobe Reader 9 acrord32.exe gets started as a subprocess of Firefox and (1) is Fx dir. So first sqlite.dll found by Adobe Reader is the one in System32.

    
    

    
  
(In reply to bug 451944 comment #6)
> (In reply to bug 451944 comment #5)
> > Branch displays PDF inside Firefox which it shouldn't do.
> > Trunk opens Adobe Reader as external app and PDF gets displayed inside Adobe Reader, which is the expected behavior.
> 
> Funny. Let's check it in bug 448102. (Already very messy, but that'll be closed
> as INVALID, so no problem to add more comments to that bug. And, we need to
> know Fx/nppdf32.dll/AcroRd32.exe behaviour before saying "Adobe's fault".)
> 

I'd say bug with wrong sqlite.dll is Adobe's fault because acrord32.exe isn't started as an independent process anymore.

Not honouring "Display PDF in Browser=Off" setting in Adobe Reader seems to be Mozilla's fault as it works in trunk but not in branch.
This seems to be bug 147309 (Ignoring Adobe Acrobat reader settings for "Display PDF in Browser"), an old bug from 2002.

    
    

    
  
kev: please find a contact for adobe acrobat's browser plugin
Assignee: nobody → kev

    
    

    
  
(In reply to comment #72)
> (In reply to comment #70)
> > NSPR log (all:5) loading PDF in a different tab
> 
> Following log is seen.
> > 00001693 4.12012196 [6208] 0[628140]: Range: bytes=549534-553629,549534-549535
> Completely same "Range: bytes=549534-553629,549534-549535" request is seen in
> your first log too(see Comment #45). I think this funny "Range:" doesn't have
> relation to this bug's issue. But it may produce other problem.
> (I can't imagine environment where network error always occurs at same point. I
> can't guess reason why over-wrapping "549534-553629,549534-549535".)
> This kind of funny phenomenon makes problem analysis difficult. Please get logs
> with same local PDF.

I'm looking into this bug (thanks kev for finding me), but in the meantime I want to mention that this "funny overlapping range" is due to a firefox bug with byte-ranges in bug 425284.  This is leftover from pre-Netscape 3.0 (according to comments in our plug-in) and is still the case (I checked with the sources).

In the case that we want only a single range, we re-request the first two bytes with a second range so the multiple-range functionality in Firefox is invoked and the correct values are returned; we throw that range away when it arrives.

On our Unix plug-in, BTW, we split the range in half rather than have an overlapping request.  I like that better but it's difficult to put changes in if it "ain't broke".

    
    

    
  
Thanks, Manfred, for finding the specific user-agent issue (and WADA for staying with him).  I've entered bug 455627 to match this one, and will work on getting the fix into a Reader patch ...and obviously I can't speculate when that might happen -- even if I could my paycheck depends on keeping mum :(

I've pointed this bug out to others here and they'll look into what appears to be the sqlite problem but I don't have any information about that.

    
    

    
  
Bug 461344 is request of "SQLite version check" for Firefox.
I think Adobe Reader is better to have feature of "warning about old sqlite.dll", instead of merely crash upon load&call of old sqlite.dll.

    
  
Component: Plug-ins → PDF (Adobe)
Flags: blocking1.9.0.2-
Product: Core → Plugins
QA Contact: plugins → adobe-reader
Version: 1.9.0 Branch → unspecified

    
    

    
  
with Bug 461344 fixed, do we still care about this?

    
    

    
  
(In reply to comment #107)
> with Bug 461344 fixed, do we still care about this?

Wayne, Firefox's Bug 461344 is irrelevant to this bug.

Three different sqlite.dll exists in this bug.
(a) sqlite3.dll in Firefox's program directory
    (it seems changed to mozsqlite3.dll by Fx4, for further safety) 
(b) sqlite.dll in Adobe Reader's program directory
(c) sqlite.dll in Windows\system32 directory (very old one in this bug's case)

When Fx is started ordinarily, (a) is loaded by OS, and no problem occurs in Fx.
Bug 461344 is for Fx's version check of (a) in case that some one(plugin, add-on, ...) loads sqlite3.dll from different library before Fx requests load of sqlite3.dll.

When Adobe Reader is started ordinarily or is invoked as stand alone process, (b) is loaded by OS and is used by Adobe Reader, and no problem occurs in Adobe Reader. Please note that dll file name is different from dll which Fx uses. 

However, when Adobe Reader is invoked by Adobe's pdf plungin which is called by Fx3 or later, AcroRd32.exe is invoked as sub-process or a thread of Fx by spec change of Fx or Adobe Reader.
In this case, sqlite.dll is not loaded from Adobe Reader's program directory due to spec change in dll-load-library-search-order of Win. sqlite.dll which is requested by AcroRd32.exe is loaded from (c) due to the spec change of Win.
This caused crash in AcroRd32.exe. This is reason why "version check of sqlite.dll by Adobe Reader" is needed. This "version check by Adobe Reader" is different thing from Bug 461344 of Firefox.
 
As "isolation of plugin processes from Fx's process" is already implemented, impact of crash in Adobe Reader/Adobe PDF plugin is lowered than before.
And, analysis of problem of Adobe Reader/Adobe PDF plugin itself should be done at outside of B.M.O.
I think this bug should be closed, but I don't know appropriate close code.
 (a) Very old sqlite.dll in system32 can be called user error.
 (b) But crash in AcroRd32.exe can be called Adobe Reader's bug.
 (c) And, crash of Firefox due to crash in AcroRd32.exe can be called Fx's bug.
I guess crash in AcroRd32.exe doesn't produce crash of Fx, as crash in plugin won't produce crash of Fx any more by enhancemet of Fx. If Fx won't crash by this bug's problem, FIXED(or WORKSFORME) may be better than INVALID or WONTFIX.

    
    

    
  
This was fixed in the recently-released Reader 9.4.2, which uses Isolated-applications to make sure it loads the correct instance of each library (including sqlite.dll).

    
  
Assignee: kev → rsherry
Crash Signature: [@ kernel32.dll@0x442eb - AcroRd32.dll@0xef2be]

    
    

    
  
I suppose Firefox could patch the system's LoadLibrary() function so when Reader tries to load sqlite the one in system32 gets skipped...

However, I think this should be marked as Closed/Fixed, as it was fixed with a release to Reader.  Isn't that the same criteria by which Firefox closes bugs in its own code -- when a patch gets incorporated and shipped?  If users refuse to update Reader, but still want to update Firefox, there isn't much we can do here at Adobe.
Status: NEW → RESOLVED
Closed: 16 years ago → 12 years ago
Resolution: --- → FIXED
Product: Plugins → Plugins Graveyard

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: