crystal error

Hi all .

I create an exexutable application with inno setup. The application shows
reports with crystal reports 10.

I distribute all files ( dlls and ocx )l which the documentation says are
necessary for Crystal

But when I execute the application and i go to open a report the follwing
error happends.

Some one can help me to interpretate the situation?



TIA

Pablo

************************** Dolphin Virtual Machine Dump Report
***************************

02:47:06, 03/01/2005: HRESULT Error: Invalid TLV record. (FACILITY_ITF)

*----> VM Context <----*

Process: {075C0004:size 275 words, suspended frame 075C0605, priority 5,
callbacks 1

last failure 0:nil, FPE mask 3, thread nil}

Active Method: SessionManager>>logError:

IP: 06FCA89D (13)

SP: 075C04FC

BP: 075C04D4 (292)

ActiveFrame: {075C04D8: cf 075C04BD, sp 075C04EC, bp 075C04D4, ip 5,
MenuShellSessionManager(SessionManager)>>logError:}

receiver: a MenuShellSessionManager

arg[0]: a HRESULTError



New Method: VMLibrary>>dump:path:stackDepth:walkbackDepth:

Message Selector: #dump:path:stackDepth:walkbackDepth:

*----> Stack Back Trace <----*

{075C04D8: cf 075C04BD, sp 075C04EC, bp 075C04D4, ip 5,
MenuShellSessionManager(SessionManager)>>logError:}

receiver: a MenuShellSessionManager

arg[0]: a HRESULTError

{075C04BC: cf 075C04A1, sp 075C04CC, bp 075C04B8, ip 4,
MenuShellSessionManager(SessionManager)>>unhandledException:}

receiver: a MenuShellSessionManager

arg[0]: a HRESULTError

{075C04A0: cf 075C0485, sp 075C04B0, bp 075C049C, ip 4,
MenuShellSessionManager(SessionManager)>>onUnhandledError:}

receiver: a MenuShellSessionManager

arg[0]: a HRESULTError

{075C0484: cf 075C046D, sp 075C0494, bp 075C0484, ip 5,
HRESULTError(Error)>>defaultAction}

receiver: a HRESULTError

{075C046C: cf 075C0459, sp 075C047C, bp 07280010, ip 57,
HRESULTError(Exception)>>_propagateFrom:}

receiver: a HRESULTError

arg[0]: a ExceptionHandler

temp[0]: nil

temp[1]: a ExceptionHandler

temp[2]: nil

temp[3]: a Process('Main' base 075C0000 [ACTIVE] in
SessionManager>>logError: sp=00000000 ip=8 list=nil)

temp[4]: nil

{075C0458: cf 075C043D, sp 075C0468, bp 075C0454, ip 6,
HRESULTError(Exception)>>_propagate}

receiver: a HRESULTError

temp[0]: nil

{075C043C: cf 075C0425, sp 075C044C, bp 075C043C, ip 12,
HRESULTError(Exception)>>signal}

receiver: a HRESULTError

{075C0424: cf 075C03F1, sp 075C0434, bp 075C0408, ip 45,
IDispatch>>invokeId:flags:parms:retVal:}

receiver: a IDispatch

arg[0]: 288

arg[1]: 5

arg[2]: a DISPPARAMS

arg[3]: a VARIANT

temp[0]: a DWORD

temp[1]: a EXCEPINFO

temp[2]: a LargeInteger()

{075C03F0: cf 075C03C9, sp 075C0400, bp 075C03E0, ip b,
IDispatch>>invokeId:flags:parms:}

receiver: a IDispatch

arg[0]: 120

arg[1]: 5

arg[2]: a DISPPARAMS

temp[0]: a VARIANT

{075C03C8: cf 075C03B5, sp 075C03D8, bp 07573FD0, ip 41,
IDispatch>>doesNotUnderstand:}

receiver: a IDispatch

arg[0]: Message selector: #openReport: arguments: a Array

temp[0]: 120

temp[1]: 5

{075C03B4: cf 075C0399, sp 075C03C4, bp 075C03B0, ip 4,
CrystalReportPresenter>>openReport:}

receiver: a CrystalReportPresenter

arg[0]: '.\Reportes\tareasagricolas.rpt'

{075C0398: cf 075C037D, sp 075C03A8, bp 075C0394, ip 7,
MenuShell>>tarPorUni}

receiver: a MenuShell

temp[0]: a CrystalReportPresenter

{075C037C: cf 075C0361, sp 075C038C, bp 075C0378, ip 4, Symbol>>forwardTo:}

receiver: #tarPorUni

arg[0]: a MenuShell

{075C0360: cf 075C0345, sp 075C0370, bp 075C035C, ip 5,
CommandDescription>>performAgainst:}

receiver: a CommandDescription

arg[0]: a MenuShell

{075C0344: cf 075C0329, sp 075C0354, bp 07582080, ip d, [] in
Command>>value}

receiver: a Command

{075C0328: cf 075C0315, sp 075C0340, bp 07573E10, ip 11,
BlockClosure>>ifCurtailed:}

receiver: [] @ 738006 in nil

arg[0]: [] @ 12 in Command>>value

temp[0]: nil

temp[1]: nil

temp[2]: nil

{075C0314: cf 075C02F5, sp 075C0324, bp 075C030C, ip 4,
BlockClosure>>ensure:}

receiver: [] @ 8 in Command>>value

arg[0]: [] @ 12 in Command>>value

temp[0]: nil

{075C02F4: cf 075C02E1, sp 075C0304, bp 07582080, ip 17, Command>>value}

receiver: a Command

{075C02E0: cf 075C02CD, sp 075C02F0, bp 07573F98, ip 1a,
ShellView>>performCommand:}

receiver: a ShellView

arg[0]: a Command

{075C02CC: cf 075C02B1, sp 075C02DC, bp 075C02C8, ip 5,
MenuShell(Shell)>>performCommand:}

receiver: a MenuShell

arg[0]: a Command

{075C02B0: cf 075C028D, sp 075C02C0, bp 075C02A4, ip e,
CommandQuery>>perform}

receiver: a CommandQuery

temp[0]: a Command

temp[1]: nil

temp[2]: a MenuShell

{075C028C: cf 075C026D, sp 075C029C, bp 075C0284, ip a,
DelegatingCommandPolicy(CommandPolicy)>>route:}

receiver: a DelegatingCommandPolicy

arg[0]: a CommandDescription

temp[0]: a CommandQuery

{075C026C: cf 075C0251, sp 075C027C, bp 07573B00, ip c, [] in
ShellView(View)>>onCommand:}

receiver: a ShellView

arg[0]: a CommandDescription

temp[0]: nil

{075C0250: cf 075C023D, sp 075C0268, bp 07582010, ip 11,
BlockClosure>>ifCurtailed:}

receiver: [] @ 738006 in nil

arg[0]: [] @ e in Cursor>>showWhile:

temp[0]: nil

temp[1]: nil

temp[2]: nil

{075C023C: cf 075C021D, sp 075C024C, bp 075C0234, ip 4,
BlockClosure>>ensure:}

receiver: [] @ 7 in View>>onCommand:

arg[0]: [] @ e in Cursor>>showWhile:

temp[0]: nil

{075C021C: cf 075C0209, sp 075C022C, bp 07573F60, ip 17, Cursor>>showWhile:}

receiver: a Cursor

arg[0]: [] @ 7 in View>>onCommand:

temp[0]: nil

temp[1]: a ExternalHandle

{075C0208: cf 075C01F5, sp 075C0218, bp 07573B00, ip e,
ShellView(View)>>onCommand:}

receiver: a ShellView

arg[0]: a CommandDescription

temp[0]: nil

{075C01F4: cf 075C01E1, sp 075C0204, bp 07573A90, ip 18,
ShellView(View)>>wmCommand:wParam:lParam:}

receiver: a ShellView

arg[0]: 111

arg[1]: 5055

arg[2]: 0

temp[0]: 5055

temp[1]: a CommandDescription

temp[2]: nil

{075C01E0: cf 075C01B5, sp 075C01F0, bp 075C01CC, ip 17,
ShellView(View)>>dispatchMessage:wParam:lParam:}

receiver: a ShellView

arg[0]: 111

arg[1]: 5055

arg[2]: 0

temp[0]: nil

temp[1]: #wmCommand:wParam:lParam:

{075C01B4: cf 075C0199, sp 075C01C4, bp 07573CF8, ip 3a, [] in
InputState>>wndProc:message:wParam:lParam:cookie:}

receiver: a InputState

arg[0]: 501b2

arg[1]: 111

arg[2]: 5055

arg[3]: 0

arg[4]: 97d7e

temp[0]: a ShellView

{075C0198: cf 075C017D, sp 075C01B0, bp 07573AC8, ip 11,
BlockClosure>>ifCurtailed:}

receiver: [] @ 738006 in nil

arg[0]: [] @ 8 in ProcessorScheduler>>callback:evaluate:

temp[0]: nil

temp[1]: nil

temp[2]: nil

{075C017C: cf 075C0169, sp 075C0194, bp 07573CC0, ip d,
ProcessorScheduler>>callback:evaluate:}

receiver: a ProcessorScheduler

arg[0]: 97d7e

arg[1]: [] @ 34 in InputState>>wndProc:message:wParam:lParam:cookie:

{075C0168: cf 075C014D, sp 075C0178, bp 07573CF8, ip 3d,
InputState>>wndProc:message:wParam:lParam:cookie:}

receiver: a InputState

arg[0]: 501b2

arg[1]: 111

arg[2]: 5055

arg[3]: 0

arg[4]: 97d7e

temp[0]: a ShellView

{075C014C: cf 075C0131, sp 075C0164, bp 075C0148, ip 20,
InputState>>pumpMessage:}

receiver: a InputState

arg[0]: a MSG

{075C0130: cf 075C0109, sp 075C0140, bp 075C0120, ip 16,
InputState>>loopWhile:}

receiver: a InputState

arg[0]: [] @ 6 in InputState>>mainLoop

temp[0]: a MSG

temp[1]: true

temp[2]: [] @ 5 in SessionManager>>forkMain

{075C0108: cf 075C00F5, sp 075C0118, bp 07573C50, ip c,
InputState>>mainLoop}

receiver: a InputState

{075C00F4: cf 075C00E1, sp 075C0104, bp 07573B70, ip d, [] in
InputState>>forkMain}

receiver: a InputState

{075C00E0: cf 075C00CD, sp 075C00F0, bp 07573C88, ip b,
ExceptionHandler(ExceptionHandlerAbstract)>>markAndTry}

receiver: a ExceptionHandler

temp[0]: nil

{075C00CC: cf 075C00B1, sp 075C00DC, bp 07573BE0, ip 15, [] in
ExceptionHandler(ExceptionHandlerAbstract)>>try:}

receiver: a ExceptionHandler

arg[0]: [] @ 8 in InputState>>forkMain

temp[0]: nil

temp[1]: nil

temp[2]: a Process('Main' base 075C0000 [ACTIVE] in
SessionManager>>logError: sp=00000000 ip=8 list=nil)

{075C00B0: cf 075C009D, sp 075C00C8, bp 07573C18, ip 11,
BlockClosure>>ifCurtailed:}

receiver: [] @ 738006 in nil

arg[0]: [] @ 22 in ExceptionHandlerAbstract>>try:

temp[0]: nil

temp[1]: nil

temp[2]: nil

{075C009C: cf 075C007D, sp 075C00AC, bp 075C0094, ip 4,
BlockClosure>>ensure:}

receiver: [] @ f in ExceptionHandlerAbstract>>try:

arg[0]: [] @ 22 in ExceptionHandlerAbstract>>try:

temp[0]: nil

{075C007C: cf 075C0069, sp 075C008C, bp 07573BE0, ip 27,
ExceptionHandler(ExceptionHandlerAbstract)>>try:}

receiver: a ExceptionHandler

arg[0]: [] @ 8 in InputState>>forkMain

temp[0]: nil

temp[1]: nil

temp[2]: a Process('Main' base 075C0000 [ACTIVE] in
SessionManager>>logError: sp=00000000 ip=8 list=nil)

{075C0068: cf 075C0049, sp 075C0078, bp 075C0060, ip 7,
BlockClosure>>on:do:}

receiver: [] @ 8 in InputState>>forkMain

arg[0]: ProcessTermination

arg[1]: [] @ c in BlockClosure>>newProcess

{075C0048: cf 00000001, sp 075C0058, bp 07573BA8, ip 11, [] in
BlockClosure>>newProcess}

receiver: [] @ 8 in InputState>>forkMain

temp[0]: nil

<Bottom of stack>

***** End of dump *****

Pablo,

I expected to be displeased with myself for not remembering what a TLV
might be, in COM speak.  Instead of something COM related, Google turned
up this: "In our experience this is most typically generated when
viewing a version 9.x Crystal Report report file (.rpt) with Crystal
Ease 2.0.  This version of Crystal Ease is not compatible with version
9.x Crystal Reports files."

Failing that as an explation, it might not hurt to check that you have
registered anything COM related, and if you have a dependency checker,
to verify that the binaries are happy on the target machine.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

[I doubt whether anyone but Blair can answer this one]

Blair,

Pablo Digonzelli wrote:

> ************************** Dolphin Virtual Machine Dump Report
> ***************************
[...]
> {075C03F0: cf 075C03C9, sp 075C0400, bp 075C03E0, ip b,
> IDispatch>>invokeId:flags:parms:}

I'm confused by what's happening here with the IP number here.

Hitherto I've thought I've seen a consistent difference between dumps produced
by actual crashes (and VMLibrary>>crashDump) and by
VMLibrary>>dump:path:stackDepth:walkbackDepth:.

Dumps produced by crashes start with:
    Dolphin Crash Dump Report
(eliding lots of stars) and end with:
    End of crash report
and record the IP numbers in HEX (lower-case, and with no hex marker).

OTOH dumps produced by #dump:path:... start with:
    Dolphin Virtual Machine Dump Report
and end with:
    End of dump
and record the IP numbers in DECIMAL.

The reason I care is, of course, that I need to decode the IP numbers correctly
for Ghoul to operate properly.

But Pablo's example is clearly a 'Dolphin Virtual Machine Dump Report' (not a
crash dump) so I'd expect it to have decimal IP numbers, but they are in hex.
Which breaks Ghoul's parser[*].

So I've obviously jumped to the wrong conclusion about how IP numbers are
recorded by the VM.  What's the real story please ?

    -- chris


[*] BTW, Pablo's example is too badly mangled by OE's line wrapping (or
something) for Ghoul's parser anyway -- even the much more robust version that
I haven't yet put on the Web -- but even with the wrapping repaired by hand,
the IP number problem makes Ghoul virtually useless.

Chris,

> [*] BTW, Pablo's example is too badly mangled by OE's line wrapping (or
> something) for Ghoul's parser anyway -- even the much more robust version that
> I haven't yet put on the Web -- but even with the wrapping repaired by hand,
> the IP number problem makes Ghoul virtually useless.

Not at all a solution, could you have a checked command item that
selects the IP parsing?  In general, I hope that OA can do something
(XML??) with the format to help Ghoul in cases like this.  IMHO, any
loss in readability would be well spent to have a reliable debugger-like
view of the output.  Thanks for building it!

Re any format madness, could it be that the udpated VM (per the MS
testing tools or whatever it was) does things differently.  Perhaps you
and Pablo are using different versions of it.

Some time ago, I posted an InnoSetup script to update the Dolphin
binaries.  No warranties, but it appears not to have killed any machines
of mine.  I can post an updated version if you are interested.  Also,
note that if you launch Dolphin via MSI shortcuts, then Windows _might_
decide to repair Dolphin and undo efforts to replace the DLLs???  Even
if it's not supposed to happen, it's worth considering as you try to
sort out any discrepancies.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

> > the IP number problem makes Ghoul virtually useless.
>
> Not at all a solution, could you have a checked command item that
> selects the IP parsing?

It doesn't look as if Blair's going to reply (and there might not be anything
useful he could tell me anyway), I supose that's the best I can do.

BTW, thank you for the encouragement.  I was inclining towards just pulling
Ghoul, but I'll soldier on with it for a while...

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
Sorry Chris, I replied in my head, but the words got no further.

Its a bug in the VM dump I'm afraid. The dump uses C++ iostreams, and so I
suppose they are just initialised differently through different paths. I
rarely use the IP values, so I can't say I had noticed they were sometimes
hex and sometimes decimal.

Briefly looking at the code, however, I would have thought that if you went
through VMLibrary>>dump:path:&c then the IPs (and BPs) would initially be in
decimal, but a dump resulting from an actual crash, or one from
VMLibrary>>crashDump: (which raises an exception, and so is effectively the
same as a real crash except that the VM does not exit), will print both
values in hex. However the printing of various object types as the dump
progresses might switch the stream between hex or decimal modes, so
unfortunately I don't think you can rely on the IP one way or another,
rendering it useless for your purposes. Its easy to fix of course, but
requires a new VM to be distributed.

Regards

Blair

Blair,

> unfortunately I don't think you can rely on the IP one way or another,
> rendering it useless for your purposes. Its easy to fix of course, but
> requires a new VM to be distributed.

The VM, stubs, and compiler already need to be touched up (unless you
rebuilt the installers??), so this might be a good excuse to package it
all (the test hooks, complier fixes for temps in the debugger, etc.).
You are most welcome to my InnoSetup script if it will help.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Blair,

> Sorry Chris, I replied in my head, but the words got no further.

<grin/>


> However the printing of various object
> types as the dump progresses might switch the stream between hex or
> decimal modes, so unfortunately I don't think you can rely on the IP one
> way or another, rendering it useless for your purposes.

Ouch!

Thanks for the info :-(

OK, I'll add a toggle between "assume hex"/"assume decimal" which defaults to
the value indicated by the type of the dump (and may as well make it notice
that a decimal value of, say, b is not sensible...)


> Its easy to fix
> of course, but requires a new VM to be distributed.

If you do chose to fix this, could you ensure that there is some way that Ghoul
can tell that it's looking at the results from a fixed VM, please ?  For
instance you could write the numbers as explicit hex (0x12).  Or use a
different "tag-line" for the header of the dump.

BTW, if you are looking at this at all, then there's another problem for Ghoul
(which I haven't mentioned before because I'm not sure that it affects anyone),
which is that -- as far as I can see -- a VM running on a XP box will always
write the timestamp in locale-specific form, whereas the same image on Win2k
will use the US locale.  If that's awkard to fix then please don't bother; it's
not very important and I already have code (not yet released) for a workaround.

    -- chris