Evening,
I've got a highly irritating bug with the reportviewer control that
appears to be a show-stopper for one of our bigger applications we're
writing.
When I try and print more than 1 page of any given report, I the
application hangs, a Window comes up saying "printing page 2 of y", and
after a period of waiting for the mysterious page to print, VS2005
throws the following error:
"ContextSwitchD eadlock was detected
Message: The CLR has been unable to transition from COM context
0x1afca0 to COM context 0x1afe10 for 60 seconds. The thread that owns
the destination context/apartment is most likely either doing a non
pumping wait or processing a very long running operation without
pumping Windows messages. This situation generally has a negative
performance impact and may even lead to the application becoming non
responsive or memory usage accumulating continually over time. To avoid
this problem, all single threaded apartment (STA) threads should use
pumping wait primitives (such as CoWaitForMultip leHandles) and
routinely pump messages during long running operations."
I'll try & provide all the information I can....
Steps to reproduce this are easy: Create new application (any
language). Add report-viewer to form, create new report, add a
text-box, bind viewer to new report, run. The report displays fine in
the control, pressing the print button brings up the usual dialogue-box
(rather slowly I might add), keep default settings, and press Print.
The printer in question is an OKI C5250n, running on a HTTP protocol
(Internal DNS address is http://okiprinter.companyinquestion.com/ipp),
and the driver version is the latest version (1.2.4).
I've tried this on several workstations. All Windows XP machines will
not print any reports to this printer, yet every other application
prints just fine (Crystal Reports included) - it's just the WinForms
ReportViewer. The only exception appears to be Windows Server 2003
which seems to print just fine from the control. All WinXP machines are
also completely up-to-date with patches.
Also, even when a report is just one page (like in our single-textbox
example), the report-viewer seems to add another phantom page to the
end which is what appears to be causing the problems.
Finally, printing to another printer seems to work ok too, it's just
this one. This would suggest environmental issues with that printer;
however, it has worked perfectly with every other application we're
tried - Microsoft and non-Microsoft.
Please would someone help me with this one! I'm desperately trying to
convince management this problem is just a fluke, and the MS Reporting
system so far has been very good - but this is a show-stopper!
Thanks in advance,
Sam
I've got a highly irritating bug with the reportviewer control that
appears to be a show-stopper for one of our bigger applications we're
writing.
When I try and print more than 1 page of any given report, I the
application hangs, a Window comes up saying "printing page 2 of y", and
after a period of waiting for the mysterious page to print, VS2005
throws the following error:
"ContextSwitchD eadlock was detected
Message: The CLR has been unable to transition from COM context
0x1afca0 to COM context 0x1afe10 for 60 seconds. The thread that owns
the destination context/apartment is most likely either doing a non
pumping wait or processing a very long running operation without
pumping Windows messages. This situation generally has a negative
performance impact and may even lead to the application becoming non
responsive or memory usage accumulating continually over time. To avoid
this problem, all single threaded apartment (STA) threads should use
pumping wait primitives (such as CoWaitForMultip leHandles) and
routinely pump messages during long running operations."
I'll try & provide all the information I can....
Steps to reproduce this are easy: Create new application (any
language). Add report-viewer to form, create new report, add a
text-box, bind viewer to new report, run. The report displays fine in
the control, pressing the print button brings up the usual dialogue-box
(rather slowly I might add), keep default settings, and press Print.
The printer in question is an OKI C5250n, running on a HTTP protocol
(Internal DNS address is http://okiprinter.companyinquestion.com/ipp),
and the driver version is the latest version (1.2.4).
I've tried this on several workstations. All Windows XP machines will
not print any reports to this printer, yet every other application
prints just fine (Crystal Reports included) - it's just the WinForms
ReportViewer. The only exception appears to be Windows Server 2003
which seems to print just fine from the control. All WinXP machines are
also completely up-to-date with patches.
Also, even when a report is just one page (like in our single-textbox
example), the report-viewer seems to add another phantom page to the
end which is what appears to be causing the problems.
Finally, printing to another printer seems to work ok too, it's just
this one. This would suggest environmental issues with that printer;
however, it has worked perfectly with every other application we're
tried - Microsoft and non-Microsoft.
Please would someone help me with this one! I'm desperately trying to
convince management this problem is just a fluke, and the MS Reporting
system so far has been very good - but this is a show-stopper!
Thanks in advance,
Sam