Skip to Content
avatar image
Former Member

Report.Close() Hangs in TS Environment Only

I have an issue that was previously posted on SCN, which has never been resolved.

Link to the full thread/post is :

The last post that remains unanswered for the past 2 months is:

Hi Don

Have disabled AV (ESET) and the app still hangs. Closed all other programs and am the only user logged on to the TS server in a Virtual Lab environment which is a replica of production environment.

Using Process Explorer shows that the app spawns the process splwow64.exe (OS's Print driver host for 32bit applications). The report object has been loaded into memory, initialized, connected to DB tables and parameters set.

At this point, the report has not been rendered, exported, displayed or printed. The user cancels out of the Choose Printer dialogue and the app tries to dispose of the report and hangs. So this proves that it is independent of a PARTICULAR printer in the TS environment.

The splwow64.exe process remains in memory, pointing to its involvement in reportDocument.Close() not completing.

The Diagnostic Trace ends off exactly the same as my previous post, indicating that the last 2 Closing Engine commands never complete. A copy of the temp report is also still left in the temp folder alongside the log files.

Would appreciate any further advice or diagnostic tests we can conduct to resolve this.

Add comment
10|10000 characters needed characters exceeded

  • Follow
  • Get RSS Feed

5 Answers

  • Best Answer
    Feb 21, 2017 at 09:57 PM

    Hi David,

    Possibly it's related to the Framework. DEV has found a few problems with 4.6 not being 100% backward compatible.

    SP 19 is now out see if that works for you.

    They have found that some things work on Windows 8.1 and 10 but not work on 7 and 2008 and the opposit is true also.

    Going back to 4.0 framework in your app may fix the issues also.


    Add comment
    10|10000 characters needed characters exceeded

  • Nov 21, 2016 at 02:56 PM

    Hi David,

    Try SP 18, we don't fix older Service Packs so first thing to do is try the latest.

    So who's Print Dialog API are you using? Since you are not rendering, exporting, displaying or printing from CR it must be the OS's Printers Common Dialog box, correct? If you are not calling CR to do anything it doesn't prove anything.

    Did you set the Viewers print button to PrintOutPutController ( POC) or PrintToPrinter (P2P)? You can do that in code or in the property of the CR WinFormViewer.

    Try this App, R&D sent it to Microsoft to show them that simply printing a text file without ANY CR components loaded had an issue.

    See what happen in your environment...

    Well we did it again, we used to be able to rename zip file to *.txt but that is no longer working so I'll attach each file so you can rebuilt the project. Remove the txt extension and change the extension to .cs

    The first file is the text file being printed, all others are the source.







    long-text.txt (461.9 kB)
    form1cs.txt (3.9 kB)
    programcs.txt (505 B)
    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Dec 06, 2016 at 09:34 AM

    Hi Don

    Thanks for the reply. Installation of SP18 has not resolved the problem. I also used the R&D Report Document app supplied to print the long document in the TS environment. A 150 page document printed to the printer without any problem.

    "So who's Print Dialog API are you using? Since you are not rendering, exporting, displaying or printing from CR it must be the OS's Printers Common Dialog box, correct? If you are not calling CR to do anything it doesn't prove anything." What I'm trying to say here, is that the problem is already in existence before any printing or exporting is done. When the ReportDocument that has been set up in memory has the Close() command issue to dispose of it, this never completes.

    Incidentally, the methods called on the ReportDocument are ExportToDisk and PrintToPrinter, but these are mute points, since the report engine appears to never complete closing 2 instances. For reference an extract of the previously posted logs that shows this is included hereafter.

    Please provide further direction so we can resolve this longstanding issue.



    Repeated the same procedure on the TS Server and reviewed the logs, noting that there are 2 missing "Closing engine" completions and the last count in the log is "2" and not "0" as with the successful environment above:

    1. |7927829d-5d6b-e434-6975-6c2aaf328825|2016 06 13 14:23:18:327|+0200|==| | |Diagnostics| 3372|2388|| ||||||||||||||||||||||..\..\src\crpe\crpe.cpp:759,Closing engine,Start Time,"14:23:18"
    2. |a265abcd-970f-0214-b9e4-9588708d7f36|2016 06 13 14:23:18:327|+0200|==| | |Diagnostics| 3372|2388|| ||||||||||||||||||||||..\..\src\crpe\crpe.cpp:801,Closing engine,Before close engine use count,"3"
    3. |4a414d44-a8b2-e194-69c4-dd8048b96179|2016 06 13 14:23:18:328|+0200|==| | |Diagnostics| 3372|2388|| ||||||||||||||||||||||..\..\src\crpe\crpe.cpp:826,Closing engine,After close engine use count,"2"
    4. |89b07cb7-077b-34c4-fbdf-f2c157a778e9|2016 06 13 14:23:18:328|+0200|==| | |Diagnostics| 3372|2388|| ||||||||||||||||||||||N/A:-1,Closing engine,Elapsed Time,"0"
    5. |33073c58-e20c-2254-a8eb-dd1bfde75b81|2016 06 13 14:23:18:333|+0200|==| | |Diagnostics| 3372|3988|| ||||||||||||||||||||||..\..\src\crpe\crpe.cpp:759,Closing engine,Start Time,"14:23:18"
    6. |8cdd83db-8250-4414-3ae7-6708b4ac963d|2016 06 13 14:24:58:366|+0200|==| | |Diagnostics| 3372|2388|| ||||||||||||||||||||||..\..\src\crpe\crpe.cpp:759,Closing engine,Start Time,"14:24:58"

    This is exactly the same version of app in both instances and the report is a blank report with no datasource or any objects on the canvas ie the report is completely discounted as a source of error.

    Logging within the App, hangs on the reportDocument.Close() call.

    Add comment
    10|10000 characters needed characters exceeded

  • Dec 06, 2016 at 10:56 PM

    Hi David,

    Thanks for following up on this new Community site.

    Looking at our source code the Closing engine 3 count is unloading OLE Objects.

    In Closing engine 2 it's then attempting to unload the XML files that we generate while processing a report., we'll load dependencies even if nothing is in the report:

    Line 826 is this:

    825 if (PEApp::GetApp()->getXalanLibraryInit() )

    826 { 827 CSLIB_NAMESPACE::TerminateXalan();

    828 }

    Xalan is a Java C++ function.

    So it appears Terminal Server is not allowing crpe32.dll to unload a dll we loaded, or shared.

    Anything in the event log or possibly your/their AV software that could be blocking access?

    It could be java.exe is old or too new possibly....


    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Dec 15, 2016 at 07:51 AM

    Hi Don

    Many thanks for your efforts.

    We have tested this on various versions of Java on a couple of similar TS environments, with all of them failing. We did not manage to track down Java log files and nothing appears to be logged and visible in Windows Event Viewer. AV has been disabled during testing. Data Execution Protection (DEP) was also disabled for regular applications, to no avail.

    Our next step was to replicate this on other OS environments other than the original Windows Server 2008 R2 TS. Testing on Windows Server 2008 (not R2) also failed. However, testing on Windows Server 2012 R2 resolved the issue!

    So whilst that brings a solution to the issue, it is still only a workaround and involves a lot of work and cost to upgrade the production environment OS.

    If this casts any light on the issue from your perspective, a proper fix in Windows 2008 R2 environment would still be first prize.

    Would appreciate your comments


    Add comment
    10|10000 characters needed characters exceeded