We have an asp.net 1.1 web application that relies on heavy client side scripting. The web application uses Forms Authentication and only authenticated users can access the pages within the site.

We get the above meeting the following repro steps:

1. A javascript script function opens a window (Window A) from an aspx page (Default page).

2. Window A opens a new window Window B that contains a PDF stream.

3. User closes Window A, and then click on the log out link on the Default page.

The user will intermittently get an unresponsive IE affecting both windows - window containing the Default page and the window containing the PDF.  Sometimes all affected IE windows close automatically.  The Acrobat Reader process are usually still running after the IE windows are closed.  It happens more regularly remotely. 

Using Fiddler to trace - when the logout link is clicked, there is no sign of a request being made back to the server (for the log out).

The problem is repro-able on multiple PCs all running IE6 fully patched.  BHOs, malwares have been ruled out.

I have search through support.microsoft.com for any clues including uninstalling some recent kb updates as well as turning on/off HTTP 1.1 but none of them fixes the problem.

Please help. 

Siew Fai Hoy

MCAD.

Hello sfinc:

Neither the browser nor the Acrobat Reader plugin are free of bugs, anyway it is usually scripts that prime the memory licks.

So, might be the client scripts that are causing the problems? In instance, as a blind guess, is there anything significant code attached to the onload/onunload events of those windows?

-LV

Hi,

Thanks for the response.  There are no onunload events, maybe onload event is still a lead however, it happens when the logout link is clicked, so is it likely that an onload event would fire? 

 Siew Fai

Does the same happen if Window B does not contain a PDF file?

Did you take a look in the event log?

 Leo

http://www.muller.co.il

Sorry for the late reply.

No, it doesn't seem to happen if it is not a PDF file.

I will look into it again when I return to the project.

Regards,

Siew Fai.

Does anyone have any idea what the following means?

I have tried debugging the crash dump file, but don't know where to start or what to look out for.

  ntdll.dll!_KiFastSystemCallRet@0()  
  ntdll.dll!_ZwWaitForSingleObject@12()  + 0xc 
  ntdll.dll!_RtlpWaitForCriticalSection@4()  + 0x8c 
  ntdll.dll!_RtlEnterCriticalSection@4()  + 0x46 
  ntdll.dll!_LdrpGetProcedureAddress@20()  + 0x17b 
  ntdll.dll!_LdrGetProcedureAddress@16()  + 0x18 
  kernel32.dll!7c8633a0()  
> usp10.dll!InternalStringOut()  + 0x2a4 
  usp10.dll!_ScriptTextOut@56()  + 0x178 
  usp10.dll!InternalStringOut()  + 0x2a4 

Siew Fai

you are creating the pdf when data  is streaming to the browser???...... there may be scripts that are not executing due to security reasons .......rather create the pdf on the server then using the Response object send the file to open on the browser by changing the respose headers .for ex:

Response.AddHeader("Content-Type:", "application/pdf");

The PDF stream is complete when the user closes the middle window and the log out in the first window.    It already use the correct headers, as you suggested.

I do take your point to ensure the Response ends correctly.  However, it is not that either, ... It is driving me nuts

Siew Fai

In my own experience, there are mainly two fields in which the browsers and plugins may fail: One is when your scripts make heavy updates to the DOM, say in a loop; in that case a work-around is simply desyncing the DOM updates with a setTimeout, like setTimeout("updDOM()", 1) instead of simply updDOM(). Another is with memory management in case your scripts fill big arrays or similar; for that, you simply nullify your objects before leaving the page, possibly in onunload.

This said, yours indeed sounds like a timing issue, so I would too suggest you revise the pdf generation cycle...

-LV

Thanks for everyone's help.

 Indeed it was due to an onbeforeunload code in Window A.  It was crapping coding at best, e.g. <body onbeforeunload= " javascript : window.parent.opener.functionName() " > some content </body>

The code was moved into a properly handled javascript function in a script block and appears to have solved the problem.

 Regards,

Siew Fai.