cancel
Showing results for 
Search instead for 
Did you mean: 

CR hangs on second report run under Win7 x64 - splwow64 issue?

markberry2
Explorer
0 Kudos

Hi,

I'm updating a VB6 program to run under Windows 7 and I'm having an issue with Crystal Reports. I've updated CR designed and merge modules to CR XI R2 SP6 (11.5.12.1838). I have not re-saved my report files since the upgrade.

My program uses RDC to generate reports in the app. The user can choose the view the report in the CRViewer, or print directly to a printer or to PDF.

Under 32-bit Windows 7, this works fine, time after time.

Under 64-bit Windows 7, the first report prints fine, but subsequent reports hang. Abbreviated code:

<Get data into an array of ADODB.Recordsets>

Set oCRXReport = oCRXAppl.OpenReport(sPathAndFileName)

oCRXReport.Database.SetDataSource ReportRsArray(ReportListArray(2, 0)), 3, 1 <-- this line hangs

oCRXReport.Export (or load oCRXReport into a CrystalActiveXReportViewer)

set oCRXReport = Nothing

I can see in Process Monitor that splwow64.exe is spawned as a child process of my app. Even after installing MS hotfix 2815716 and setting a 5-second timeout it the registry, splwow64.exe never ends.I thought it could just be re-used, so I'm not sure that's the issue. The fact that the SetDataSource line hangs makes it sound like a DB issue, but all other DB access in the app works fine, and even the reports work fine under 32-bit Win7, so I don't understand why that line is the problem.

I found a similar issue in a three-year-old post on this board. It looks like the advice was to install the latest CR XI, which I've done. Since this is happening with the native viewer, I don't think updating a print driver is an option.

Any suggestions on how to get the CR run-time to work under 64-bit Win7?

Thanks,

Mark Berry
MCB Systems

Accepted Solutions (1)

Accepted Solutions (1)

former_member183750
Active Contributor
0 Kudos

Hello Mark

Couple of ideas, but honestly all I am doing is shooting in the dark. While CR XI R2 SP 6 was technically supported on WIN 7, I suspect the testing done for it was quite minimal. I don't ever recall working with an RDC app in a 64 bit Win 7 environment my self (CR XI R2 was so old and WIN 7 was so new, the interest just was not there).

Anyhow, see if any ideas in this blog give you a clue. The blog is not specific to your issue, but...

Next, see if Process Monitor gives you any clues. I have no clue as to what to specifically look for, other than the report loads or error messages.

Oh, check the event viewer too.

- Ludek

Senior Support Engineer AGS Product Support, Global Support Center Canada

Follow us on Twitter

markberry2
Explorer
0 Kudos

Hi Ludek,

Thanks for those thoughts. I'm afraid nothing in the blog post jumped out as a possible solution. I didn't see anything relevant in event logs. Haven't yet gone so far as to turn on Object Access auditing and check the Security log.

The details of Process Explorer, can't remember if it was my app or its child process splwow64.exe, mentioned something about a DeviceWait call, which seemed to confirm a print driver as a probable cause.

I did try Process Monitor, filtered on my application's .exe name. The last thing before the hang was a call to and return from some kind of thread. No obvious "access denied" issues. Next step would be to remove the filter and check other events at that time. As you say, shooting in the dark.

It looks like I bought XI as the latest available version in July 2007. Is there a later version that would be supported for RDC and Windows 7 x64?

Regards,

Mark Berry

MCB Systems

former_member183750
Active Contributor
0 Kudos

Let's start with your last question. Of all the troubles here, that will be the most troubling one for you...

The RDC was last shipped in CR XI R2. So, yes there are later versions of CR, but none of those install the RDC. And CR XI R2 has been out of support for 2 years or so (e.g.; no phone support, no fixes). So, we'll have to keep kicking at this with CR XI R2. (Oh, the latter versions of CR  have SDKs for VS .NET and Java only)

My next idea comes from the mention of device. What happens if you enable the "No Printer" option on one of the reports - just to test.

As far as that doc, I figured it was going to be of little use, but it was worth a try.

What else...It may be worth while to simplify this to the nth degree:

New app - one form, CR viewer

New report - no db connection. One text box; "Hello World".  "No Printer" option enabled.

Two lines of code:

CRViewer1.ReportSource = "the report"

CRViewer1.ViewReport

Compile. Throw the exe on the 64 bit WIN 7 computer.

Keep your fingers crossed/

- Ludek

markberry2
Explorer
0 Kudos

Thanks, Ludek. Too bad a couple hundred dollars for an upgrade isn't an option.

Tried the "No Printer" idea on the fairly simple report I've been testing. I was hopeful, since it was set to use a network printer on a server that was decommissioned years ago. The file was last saved 5/25/2005 and asked if it is okay to update to the newer format, which I okayed. Alas, no luck; it still hangs on the second call.

I'm not clear on the role of the printer definition in the .rpt file. I've been distributing that .rpt to the client for runtime use for years. They have a completely different network environment from mine with different printers defined, and the unmatched printer definition has not been a problem. My goal, which otherwise seems to work, is for the .rpt file to be purely for formatting, with data and printer definitions provided externally.

I will have to come back to your other suggestion of creating a test app in a few weeks. The client only authorizes so many hours per month .

Thanks for your help,

Mark Berry
MCB Systems

former_member183750
Active Contributor
0 Kudos

Understood re. the upgrade. It would not be just the cost of the upgrade, but the cost of the total app rewrite. Ain't technology grand ? The silver lining is; think of the job security...

I'll be here, once you get back to this. we'll see what we can do from there.

Happy coding,

- Ludek

0 Kudos

Hi Mark,

A lot of Printers don't supported switching between platforms or "thunk" between 32 bit and 64 bits very well. I would look at the printer drivers they are using a little closer, try the latest download/update. Sometimes even the generic driver off the Windows CD works better for your app.

Try the generic XPS driver to start with also since it's relatively common and works in both platforms.... it has issues also but my help to debug.

You could always try DebugDiag from MS and see if it captures anything, we can get the PDB files for you if need be.

Anything in the Event logs? An extreme change would be to use Threading Apartment model and thread each step, one for viewer and one for printing, at least you can kill the thread.

Don

markberry2
Explorer
0 Kudos

Hi Don,

Thanks for your reply.

I get that this must be some kind of driver thunking issue, but I'm not quite understanding what control I have over the printer driver, since it happens with the Active X viewer control, i.e. without even sending to an actual printer. Setting the .rpt to use No Printer didn't help.

I didn't see anything useful in the Event logs.

Before I start with debugging and threading, I need to find out from the client whether they will even use 64-bit Win7 and how important it is to them to see this resolved.

Regards,

Mark Berry

MCB Systems

0 Kudos

Hi Mark,

I've seen issues with HP Printers for years now, seems they don't clean up behind themselves very nicely.

Their DMExtra collection where all of the "custom" options are saved in DEVMODE returned an invalid StructSize which case CR to throw an exception, there were others but I don't recall the details now...

Crystal the PC's default printer if no printer is selected or the printer the report was designed against cannot be found. Possibly it's simply trying to find the printer.

Have they let it go to see if it ever returns control back to your app?

Do they actually have the printer installed locally?

Don

markberry2
Explorer
0 Kudos

Don,

Got excited there for a minute when you mentioned that CR will use the default printer if none is defined or if the one defined is no longer available.

I am testing this on my own workstation, not at the client site. yet. It does have a network-attached Brother MFC defined, but I've had CutePDF set as default. I changed the default to Microsoft XPS Document Writer but it still hangs on the second invocation. It's stayed hung for the five minutes it has taken me to type this reply.

I'll probably need to test this from a clean(er) machine to see if it is somehow connected to old settings on this workstation. Unfortunately I don't have any other x64 machines available.

Mark Berry
MCB Systems

Answers (2)

Answers (2)

markberry2
Explorer
0 Kudos

The hangs have returned. Don't know if something is changing on my test machine. If the client wants to pursue this, I'll have to find another Win7 x64 test machine. The client may just go with 32-bit Win7 in which case this won't matter (assuming 32-bit can run the reports reliably).

markberry2
Explorer
0 Kudos

Tested this again today under Win7 x64 and this time could not duplicate the hang. splwow64.exe is still at version 6.1.7601.22268 from Hotfix 2815716. In Sysinternals Process Explorer, I can see splwow64 as a child process of my app; both go away cleanly when I close my app. In other words, everything is working as it should.

Before this, I had removed some "MsgBox" statements from my app that I had inserted for debugging, then re-compiled, but that shouldn't have made a difference.

Maybe some update to Windows since November has fixed this. It makes me nervous when something suddenly starts working, but I'll take it.

Thanks everyone for your help.

Mark Berry
MCB Systems

0 Kudos

Hi Mark,

Interesting.... You are not the first person to report issues recently of this type. Others have reported that running in debug mode has problems but release mode works fine... and debug works but release does not... This suggested that Microsoft has updated either one or both release and debug versions of their dll's and they are not in sync with each other.

I see this myself sometimes.... But I've never heard of Message Boxes causing the issue... That's a new one for me but I'll try it next time, comment out all my message boxes..

I'm the opposite, things tend to not work on my PC or they do work but not on anyone elses PC.. it is frustrating at times... Usually a reboot fixes things up... I try to re-boot at least once a week so Windows has a chance to clean itself up, release all memory which defrag it as well as I manually clean my \temp folders out, runnign in debug mode and stopping tends to leave a lot of garbage in that folder and they can cause problems also...

I hate to say if but... "if it ain't broke don't fix it"... lol but that's hard to do these days...

Thanks again

Don

markberry2
Explorer
0 Kudos

Don,

To clarify re. message boxes:  first the app exhibited the hanging behavior, THEN I added MsgBox statements to isolate exactly which line of code was hanging. At that point (November 2013), it was still hanging and I found out on which statement. Yesterday, I just commented out those extra MsgBox statements. So I'm pretty sure adding/removing MsgBox statements had nothing to do with it.

Mark Berry
MCB Systems