Deadlock in ReportViewer?

Deadlock in ReportViewer?

• bryanedds

  Some more information - here's the two stack traces. I believe this had something to do specifically to do with an MDI host form, a child form, and a 3rd dialog form which had menus attached to them (only because the other thread that appears to be part of the deadlock is in a call to UpdateMenuHandles):

  Image Animator thread:

  > system.drawing.dll!System.Drawing.ImageAnimator.ThreadProcImpl() + 0x63 bytes

  Other thread:

  system.windows.forms.dll!System.Windows.Forms.Form.UpdateMenuHandles(System.Windows.Forms.MainMenu menu = <undefined value>, bool forceRedraw = true) + 0x164 bytes
  system.windows.forms.dll!System.Windows.Forms.Form.UpdateMenuHandles() + 0xc5 bytes
  system.windows.forms.dll!System.Windows.Forms.Form.MenuChanged(int change = 0, System.Windows.Forms.Menu menu = <undefined value>) + 0xc4 bytes
  system.windows.forms.dll!System.Windows.Forms.Form.Dispose(bool disposing = true) + 0x332 bytes
  > WindowHandleWindows.exe!WindowHandleWindows.DialogForm.Dispose(bool disposing = true) Line 48 C#
  system.dll!System.ComponentModel.Component.Dispose() + 0x13 bytes
  WindowHandleWindows.exe!WindowHandleWindows.ChildForm.button1_Click(System.Object sender = {System.Windows.Forms.Button}, System.EventArgs e = {System.EventArgs}) Line 136 + 0x32 bytes C#
  system.windows.forms.dll!System.Windows.Forms.Control.OnClick(System.EventArgs e = {System.EventArgs}) + 0x62 bytes
  system.windows.forms.dll!System.Windows.Forms.Button.OnClick(System.EventArgs e = {System.EventArgs}) + 0x56 bytes
  system.windows.forms.dll!System.Windows.Forms.Button.OnMouseUp(System.Windows.Forms.MouseEventArgs mevent = {X=37 Y=14 Button=Left}) + 0x119 bytes
  system.windows.forms.dll!System.Windows.Forms.Control.WmMouseUp(System.Windows.Forms.Message m = {System.Windows.Forms.Message}, System.Windows.Forms.MouseButtons button = Left, int clicks = 1) + 0x235 bytes
  system.windows.forms.dll!System.Windows.Forms.Control.WndProc(System.Windows.Forms.Message m = {System.Windows.Forms.Message}) + 0x4a1 bytes
  system.windows.forms.dll!System.Windows.Forms.ButtonBase.WndProc(System.Windows.Forms.Message m = {System.Windows.Forms.Message}) + 0x11c bytes
  system.windows.forms.dll!System.Windows.Forms.Button.WndProc(System.Windows.Forms.Message m = {System.Windows.Forms.Message}) + 0x8d bytes
  system.windows.forms.dll!ControlNativeWindow.OnMessage(System.Windows.Forms.Message m = {System.Windows.Forms.Message}) + 0x19 bytes
  system.windows.forms.dll!ControlNativeWindow.WndProc(System.Windows.Forms.Message m = {System.Windows.Forms.Message}) + 0xda bytes
  system.windows.forms.dll!System.Windows.Forms.NativeWindow.DebuggableCallback(int hWnd = 7931074, int msg = 514, int wparam = 0, int lparam = 917541) + 0x39 bytes
  system.windows.forms.dll!System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods+IMsoComponentManager.FPushMessageLoop(int dwComponentID = 1, int reason = -1, int pvLoopData = 0) + 0x2fa bytes
  system.windows.forms.dll!ThreadContext.RunMessageLoopInner(int reason = -1, System.Windows.Forms.ApplicationContext context = {System.Windows.Forms.ApplicationContext}) + 0x1db bytes
  system.windows.forms.dll!ThreadContext.RunMessageLoop(int reason = -1, System.Windows.Forms.ApplicationContext context = {System.Windows.Forms.ApplicationContext}) + 0x4f bytes
  system.windows.forms.dll!System.Windows.Forms.Application.Run(System.Windows.Forms.Form mainForm = {WindowHandleWindows.Form1}) + 0x37 bytes
  WindowHandleWindows.exe!WindowHandleWindows.Form1.Main() Line 107 C#
  

  
  

• Belias

  I just verified that this is fixed in Orcas Beta 1. Thanks Brian et al. Now to get the bug fix latency down to < 1 year...
  
  

• Jough

  Thank you very much for looking into this!
  
  

• Binu Jeesman

  With a little more time, I've come up with a 100% consistent repro for this. Would someone at Microsoft be interested in a bug report I'm too lazy to figure out a way to post my entire Visual Studio solution, but it's very basic. I'm on a WinXP Pro SP2 box.
  

  1. Use Visual Studio to "design" a report that has no datasets, is totally blank, but the report size is set to be very tall (e.g. 6.5 x 82 inches). I called mine LongReport.rdl
  2. Create a Windows application, add the appropriate ReportViewer dll references. In the designer for Form1, add a ReportViewer control. Edit the Form1.Load event to call the following function:
     <code>
     private void Form1_Load(object sender, EventArgs e)
     {
     this.reportViewer1.LocalReport.LoadReportDefinition(
     new StreamReader(@"LongReport.rdl"));
     this.reportViewer1.RefreshReport();
     }
     </code>
     
     Oh yeah, this means LongReport.rdl needs to be in the bin\Debug directory. I added LongReport.rdl to the project and set Copy to Output Directory = Copy if newer.
  3. Build & run the app, and do the following:
  1. Click on the Print Layout button to toggle into print layout view.
  2. Click the Page Setup button. Select Landscape, click OK.
  3. Click the Last Page button to go to the last page of the report (for me, it's page 13... page size is U.S. Letter by default)
  4. Click Page Setup again, select Portrait, click OK

  
  At this point the application hangs, as I described.
  
  
  

• RTIS1

  Thank you for reporting this issue.

  This looks like a bug, though I'm seeing different behavior. Instead of the application hang, I'm seeing a null reference exception, but given the call stack you see, I think this is just the result of the threads running such that I get by the deadlock. It's the result of the viewer trying to display a page of the report that no longer exists after the page size change. Navigating to page 1 first (or any other page that still exists) will work around the issue.

  
  

• Shrini

  Interesting that you just posted this, as I'm having a similar issue but with a simple animated GIF file on a form that does nothing but wait for a background thread to complete and then close. It certainly looks like a deadlock with the ImageAnimator class in .Net 1.1 when the form is disposed while the animator is running. Even when using form.Invoke to get back to the UI thread when closing the form, I will get a deadlock every now and then. I've got a simple repro case using nothing but base .Net framework code. I haven't tested it on .Net framework 2.0 yet... have to look into that. However, it also seems that this behavior is more likely to be exhibited in a Citrix environment than running on a normal desktop machine.

  Is there somewhere I can send the repro case Although I've found a work-around that has made the issue less common, it is still occurring.

  Doug Rohrer

  
  
• Deadlock in ReportViewer?