Installshield (with Roller Coaster Tycoon demo)

[Paul Vriens]

Hi,

I know there are still issue with InstallShield, is the following one of
them?

When trying to install the above mentioned demo I get an errorbox:

------------------------
Error Number: 0x80040706
Description: Object reference not set

Setup will now terminate
------------------------

Part of the 'normal' output:

err:ole:_get_funcdesc Did not find a typeinfo for reftype 0?
err:ole:PSFacBuf_CreateProxy GetFuncDesc 80029c4a should not fail here.
err:ole:proxy_manager_create_ifproxy Could not create proxy for interface
{3d8b6331-d8b1-11d2-80c5-00104b1f6cea}, error 0x80029c4a
fixme:sync:SetNamedPipeHandleState 0xa0 0xf7cff4 (nil) (nil)
err:ole:CoUnmarshalInterface IMarshal::UnmarshalInterface failed, 0x80029c4a
fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion
from 0x4003 -> 0x8) 77e16eec
err:ole:_get_funcdesc Did not find a typeinfo for reftype 0?
err:ole:PSFacBuf_CreateProxy GetFuncDesc 80029c4a should not fail here.
err:ole:proxy_manager_create_ifproxy Could not create proxy for interface
{3d8b6331-d8b1-11d2-80c5-00104b1f6cea}, error 0x80029c4a
fixme:sync:SetNamedPipeHandleState 0x108 0xf7dd9c (nil) (nil)
err:ole:CoUnmarshalInterface IMarshal::UnmarshalInterface failed, 0x80029c4a

Cheers,

Paul Vriens.

[Marcus Meissner]

On Thu, Feb 17, 2005 at 12:06:01PM +0100, Paul Vriens wrote:
> Hi,
>
> I know there are still issue with InstallShield, is the following one of
> them?
>
> When trying to install the above mentioned demo I get an errorbox:
>
> ------------------------
> Error Number: 0x80040706
> Description: Object reference not set
>
> Setup will now terminate
> ------------------------
>
> Part of the 'normal' output:
>
> err:ole:_get_funcdesc Did not find a typeinfo for reftype 0?

You need stdole32.tlb most likely.

Ciao, Marcus

[Paul Vriens]

On Thu, 2005-02-17 at 12:59, Marcus Meissner wrote:
> On Thu, Feb 17, 2005 at 12:06:01PM +0100, Paul Vriens wrote:
> > Hi,
> >
> > I know there are still issue with InstallShield, is the following one of
> > them?
> >
> > When trying to install the above mentioned demo I get an errorbox:
> >
> > ------------------------
> > Error Number: 0x80040706
> > Description: Object reference not set
> >
> > Setup will now terminate
> > ------------------------
> >
> > Part of the 'normal' output:
> >
> > err:ole:_get_funcdesc Did not find a typeinfo for reftype 0?
>
> You need stdole32.tlb most likely.
>
> Ciao, Marcus
> Hi,

I copied over a stdole32.tlb, the error is still there. The two
(builtin/native) traces however show a difference:

With builtin stdole32.tlb:

000b:trace:ole:ITypeInfo_fnGetRefTypeInfo typeinfo in imported typelib that isn't already loaded
000b:trace:ole:WINE_StringFromCLSID 0x77eaa254->{00020430-0000-0000-C000-000000000046}
000b:trace:ole:LoadTypeLib (L"C:\\windows\\system\\stdole32.tlb",0x91d0dc)
000b:trace:ole:LoadTypeLibEx (L"C:\\windows\\system\\stdole32.tlb",0,0x91d0dc)
000b:trace:ole:LoadRegTypeLib (IID: {00020430-0000-0000-c000-000000000046}) load FAILED ((nil))
000b:trace:ole:LoadTypeLib (L"C:\\WINNT\\System32\\StdOle32.tlb",0x91d0dc)
000b:trace:ole:LoadTypeLibEx (L"C:\\WINNT\\System32\\StdOle32.tlb",0,0x91d0dc)
000b:trace:ole:ITypeInfo_fnGetRefTypeInfo (0x77ed2828) hreftype 0x0000 loaded FAILURE (0x7df4b8)
000b:err:ole:_get_funcdesc Did not find a typeinfo for reftype 0?
000b:err:ole:PSFacBuf_CreateProxy GetFuncDesc 80029c4a should not fail here.
000b:err:ole:proxy_manager_create_ifproxy Could not create proxy for interface {3d8b6331-d8b1-11d2-80c5-00104b1f6cea}, error 0x80029c4a

With native stdole32.tlb:

000b:trace:ole:ITypeInfo_fnGetRefTypeInfo typeinfo in imported typelib that isn't already loaded
000b:trace:ole:WINE_StringFromCLSID 0x77eb4454->{00020430-0000-0000-C000-000000000046}
000b:trace:ole:LoadTypeLib (L"C:\\windows\\system\\stdole32.tlb",0xa9d0dc)
000b:trace:ole:LoadTypeLibEx (L"C:\\windows\\system\\stdole32.tlb",0,0xa9d0dc)
000b:trace:ole:LoadTypeLibEx File L"C:\\windows\\system\\stdole32.tlb" index 1
000b:trace:ole:ITypeLib2_Constructor_SLTG 0x7e8702b0, TLB length = 4240
000b:trace:ole:ITypeLib2_Constructor_SLTG header:

and a bit further in the log (err/warn not present for builtin, most
likely because the builtin doesn't get this far):

000b:warn:ole:I_RpcReceive bad packet type 116
000b:trace:ole:RPCRT4_CloseBinding (Binding == ^0x7f305238)
000b:trace:ole:RPCRT4_DestroyConnection connection: 0x7e714248
000b:trace:ole:RPCRT4_CloseConnection (Connection == ^0x7e714248)
000b:trace:ole:RpcChannelBuffer_SendReceive -- 0x800706c0
000b:err:ole:xCall RpcChannelBuffer SendReceive failed, 800706c0

Cheers,

Paul.

[Robert Shearman]

Paul Vriens wrote:
> Hi,
>
> I copied over a stdole32.tlb, the error is still there. The two
> (builtin/native) traces however show a difference:
>
> With builtin stdole32.tlb:
>
> 000b:trace:ole:ITypeInfo_fnGetRefTypeInfo typeinfo in imported typelib that isn't already loaded
> 000b:trace:ole:WINE_StringFromCLSID 0x77eaa254->{00020430-0000-0000-C000-000000000046}
> 000b:trace:ole:LoadTypeLib (L"C:\\windows\\system\\stdole32.tlb",0x91d0dc)
> 000b:trace:ole:LoadTypeLibEx (L"C:\\windows\\system\\stdole32.tlb",0,0x91d0dc)
> 000b:trace:ole:LoadRegTypeLib (IID: {00020430-0000-0000-c000-000000000046}) load FAILED ((nil))
> 000b:trace:ole:LoadTypeLib (L"C:\\WINNT\\System32\\StdOle32.tlb",0x91d0dc)
> 000b:trace:ole:LoadTypeLibEx (L"C:\\WINNT\\System32\\StdOle32.tlb",0,0x91d0dc)

Does C:\WINNT exist? Looks like a bad path in your registry...
> 000b:trace:ole:ITypeInfo_fnGetRefTypeInfo (0x77ed2828) hreftype 0x0000 loaded FAILURE (0x7df4b8)
> 000b:err:ole:_get_funcdesc Did not find a typeinfo for reftype 0?
> 000b:err:ole:PSFacBuf_CreateProxy GetFuncDesc 80029c4a should not fail here.
> 000b:err:ole:proxy_manager_create_ifproxy Could not create proxy for interface {3d8b6331-d8b1-11d2-80c5-00104b1f6cea}, error 0x80029c4a
>
> With native stdole32.tlb:
>
> 000b:trace:ole:ITypeInfo_fnGetRefTypeInfo typeinfo in imported typelib that isn't already loaded
> 000b:trace:ole:WINE_StringFromCLSID 0x77eb4454->{00020430-0000-0000-C000-000000000046}
> 000b:trace:ole:LoadTypeLib (L"C:\\windows\\system\\stdole32.tlb",0xa9d0dc)
> 000b:trace:ole:LoadTypeLibEx (L"C:\\windows\\system\\stdole32.tlb",0,0xa9d0dc)
> 000b:trace:ole:LoadTypeLibEx File L"C:\\windows\\system\\stdole32.tlb" index 1

... but it doesn't happen with native stdole32.tlb. Huw, any idea why 
this is happening?
> 000b:trace:ole:ITypeLib2_Constructor_SLTG 0x7e8702b0, TLB length = 4240
> 000b:trace:ole:ITypeLib2_Constructor_SLTG header:

> and a bit further in the log (err/warn not present for builtin, most
> likely because the builtin doesn't get this far):
>
> 000b:warn:ole:I_RpcReceive bad packet type 116
> 000b:trace:ole:RPCRT4_CloseBinding (Binding == ^0x7f305238)
> 000b:trace:ole:RPCRT4_DestroyConnection connection: 0x7e714248
> 000b:trace:ole:RPCRT4_CloseConnection (Connection == ^0x7e714248)
> 000b:trace:ole:RpcChannelBuffer_SendReceive -- 0x800706c0
> 000b:err:ole:xCall RpcChannelBuffer SendReceive failed, 800706c0

This last problem is fixed in CVS. The patch that fixes it is OLE #72. I 
think we were trying to HeapFree a bad pointer, causing corruption of 
the memory allocated for receiving the packet.

Rob

[Paul Vriens]

On Fri, 2005-02-18 at 17:26, Robert Shearman wrote:
> Paul Vriens wrote:
> > Hi,
> >
> > I copied over a stdole32.tlb, the error is still there. The two
> > (builtin/native) traces however show a difference:
> >
> > With builtin stdole32.tlb:
> >
> > 000b:trace:ole:ITypeInfo_fnGetRefTypeInfo typeinfo in imported typelib that isn't already loaded
> > 000b:trace:ole:WINE_StringFromCLSID 0x77eaa254->{00020430-0000-0000-C000-000000000046}
> > 000b:trace:ole:LoadTypeLib (L"C:\\windows\\system\\stdole32.tlb",0x91d0dc)
> > 000b:trace:ole:LoadTypeLibEx (L"C:\\windows\\system\\stdole32.tlb",0,0x91d0dc)
> > 000b:trace:ole:LoadRegTypeLib (IID: {00020430-0000-0000-c000-000000000046}) load FAILED ((nil))
> > 000b:trace:ole:LoadTypeLib (L"C:\\WINNT\\System32\\StdOle32.tlb",0x91d0dc)
> > 000b:trace:ole:LoadTypeLibEx (L"C:\\WINNT\\System32\\StdOle32.tlb",0,0x91d0dc)
>
> Does C:\WINNT exist? Looks like a bad path in your registry...

There's nothing in my registry pointing to C:\WINNT. Couldn't this be
because the load FAILED for C:\\windows\\system\stdole32.tlb ?
> > 000b:trace:ole:ITypeInfo_fnGetRefTypeInfo (0x77ed2828) hreftype 0x0000 loaded FAILURE (0x7df4b8)
> > 000b:err:ole:_get_funcdesc Did not find a typeinfo for reftype 0?
> > 000b:err:ole:PSFacBuf_CreateProxy GetFuncDesc 80029c4a should not fail here.
> > 000b:err:ole:proxy_manager_create_ifproxy Could not create proxy for interface {3d8b6331-d8b1-11d2-80c5-00104b1f6cea}, error 0x80029c4a
> >
> > With native stdole32.tlb:
> >
> > 000b:trace:ole:ITypeInfo_fnGetRefTypeInfo typeinfo in imported typelib that isn't already loaded
> > 000b:trace:ole:WINE_StringFromCLSID 0x77eb4454->{00020430-0000-0000-C000-000000000046}
> > 000b:trace:ole:LoadTypeLib (L"C:\\windows\\system\\stdole32.tlb",0xa9d0dc)
> > 000b:trace:ole:LoadTypeLibEx (L"C:\\windows\\system\\stdole32.tlb",0,0xa9d0dc)
> > 000b:trace:ole:LoadTypeLibEx File L"C:\\windows\\system\\stdole32.tlb" index 1
>
> ... but it doesn't happen with native stdole32.tlb. Huw, any idea why 
> this is happening?
> > 000b:trace:ole:ITypeLib2_Constructor_SLTG 0x7e8702b0, TLB length = 4240
> > 000b:trace:ole:ITypeLib2_Constructor_SLTG header:
> > and a bit further in the log (err/warn not present for builtin, most
> > likely because the builtin doesn't get this far):
> >
> > 000b:warn:ole:I_RpcReceive bad packet type 116
> > 000b:trace:ole:RPCRT4_CloseBinding (Binding == ^0x7f305238)
> > 000b:trace:ole:RPCRT4_DestroyConnection connection: 0x7e714248
> > 000b:trace:ole:RPCRT4_CloseConnection (Connection == ^0x7e714248)
> > 000b:trace:ole:RpcChannelBuffer_SendReceive -- 0x800706c0
> > 000b:err:ole:xCall RpcChannelBuffer SendReceive failed, 800706c0
>
> This last problem is fixed in CVS. The patch that fixes it is OLE #72. I 
> think we were trying to HeapFree a bad pointer, causing corruption of 
> the memory allocated for receiving the packet.

I'm running a version of CVS that includes that one. So there is more to
it.

Cheers,

Paul.

[Krzysztof Kosz]

Paul Vriens wrote:
> On Fri, 2005-02-18 at 17:26, Robert Shearman wrote:
> > Paul Vriens wrote:
> > > Hi,
> > >
> > > I copied over a stdole32.tlb, the error is still there. The two
> > > (builtin/native) traces however show a difference:
> > >
> > > With builtin stdole32.tlb:
> > >
> > > 000b:trace:ole:ITypeInfo_fnGetRefTypeInfo typeinfo in imported typelib
> > > that isn't already loaded 000b:trace:ole:WINE_StringFromCLSID
> > > 0x77eaa254->{00020430-0000-0000-C000-000000000046}
> > > 000b:trace:ole:LoadTypeLib
> > > (L"C:\\windows\\system\\stdole32.tlb",0x91d0dc)
> > > 000b:trace:ole:LoadTypeLibEx
> > > (L"C:\\windows\\system\\stdole32.tlb",0,0x91d0dc)
> > > 000b:trace:ole:LoadRegTypeLib (IID:
> > > {00020430-0000-0000-c000-000000000046}) load FAILED ((nil))
> > > 000b:trace:ole:LoadTypeLib
> > > (L"C:\\WINNT\\System32\\StdOle32.tlb",0x91d0dc)
> > > 000b:trace:ole:LoadTypeLibEx
> > > (L"C:\\WINNT\\System32\\StdOle32.tlb",0,0x91d0dc)
> >
> > Does C:\WINNT exist? Looks like a bad path in your registry...
>
> There's nothing in my registry pointing to C:\WINNT. Couldn't this be
> because the load FAILED for C:\\windows\\system\stdole32.tlb ?
> >

Yes, it looks like a fallback. And one thing more to note (don't know if
that's matter): Linux is case sensitive (I assume that Wine also) and we
have here: {00020430-0000-0000-C000-000000000046} versus
{00020430-0000-0000-c000-000000000046} - 'C" versus 'c'. Just spotted in
the traces.

regards,
Krzysiek

[Andreas Mohr]

Hi,

On Sat, Feb 19, 2005 at 01:33:35PM +0100, Krzysztof Kosz wrote:
> Yes, it looks like a fallback. And one thing more to note (don't know if
> that's matter): Linux is case sensitive (I assume that Wine also) and we
> have here: {00020430-0000-0000-C000-000000000046} versus
> {00020430-0000-0000-c000-000000000046} - 'C" versus 'c'. Just spotted in
> the traces.
> Linux *filesystem* and *commands* are (usually!) case-sensitive, but that
> doesn't really tell anything about case sensitivity rules in any program code
> whatsoever or even any other areas...
> (although in general Unix is case sensitive mostly)

In this case I'd think it's just a printout of GUID strings, which are
*probably* always used in a case insensitive way, but then I didn't really
check it...

Andreas Mohr

[Paul Vriens]

Hi (again),

I've applied OLE#75 and OLE#76 and now I've something that doesn't look
right:

trace (without OLE75/OLE76 and with native stdole32.tlb):

000b:trace:ole:LoadTypeLib (L"C:\\windows\\system\\stdole32.tlb",0xa9d0dc)
000b:trace:ole:LoadTypeLibEx (L"C:\\windows\\system\\stdole32.tlb",0,0xa9d0dc)
000b:trace:ole:LoadTypeLibEx File L"C:\\windows\\system\\stdole32.tlb" index 1
000b:trace:ole:ITypeLib2_Constructor_SLTG 0x7e8702b0, TLB length = 4240

trace (with OLE75/OLE76 and builtin stdole32.tlb):

000b:trace:ole:LoadTypeLib (L"stdole32.tlb",0x3dd0dc)
000b:trace:ole:LoadTypeLibEx (L"stdole32.tlb",0,0x3dd0dc)
000b:trace:ole:LoadTypeLibEx File L"stdole32.tlb" index 1
000b:trace:ole:TLB_ReadTypeLib not found, trying to load L"stdole32.tlb" as library
000b:trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\stdole32.tlb" : builtin
000b:trace:ole:ITypeLib2_Constructor_MSFT 0xe31180, TLB length = 4384

trace (with OLE75/OLE76 and native stdole32.tlb copied to \windows\system):

000b:trace:ole:LoadTypeLib (L"stdole32.tlb",0x80d0dc)
000b:trace:ole:LoadTypeLibEx (L"stdole32.tlb",0,0x80d0dc)
000b:trace:ole:LoadTypeLibEx File L"C:\\windows\\system\\stdole32.tlb" index 1
000b:trace:ole:ITypeLib2_Constructor_SLTG 0x7e9602b0, TLB length = 4240

Why do we use _SLTG in the first and last trace and _MSFT in the second?

Cheers,

Paul.

[Paul Vriens]

On Mon, 2005-02-21 at 15:16, Paul Vriens wrote:
> Hi (again),
>
> I've applied OLE#75 and OLE#76 and now I've something that doesn't look
> right:
>
> trace (without OLE75/OLE76 and with native stdole32.tlb):
>
> 000b:trace:ole:LoadTypeLib (L"C:\\windows\\system\\stdole32.tlb",0xa9d0dc)
> 000b:trace:ole:LoadTypeLibEx (L"C:\\windows\\system\\stdole32.tlb",0,0xa9d0dc)
> 000b:trace:ole:LoadTypeLibEx File L"C:\\windows\\system\\stdole32.tlb" index 1
> 000b:trace:ole:ITypeLib2_Constructor_SLTG 0x7e8702b0, TLB length = 4240
>
> trace (with OLE75/OLE76 and builtin stdole32.tlb):
>
> 000b:trace:ole:LoadTypeLib (L"stdole32.tlb",0x3dd0dc)
> 000b:trace:ole:LoadTypeLibEx (L"stdole32.tlb",0,0x3dd0dc)
> 000b:trace:ole:LoadTypeLibEx File L"stdole32.tlb" index 1
> 000b:trace:ole:TLB_ReadTypeLib not found, trying to load L"stdole32.tlb" as library
> 000b:trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\stdole32.tlb" : builtin
> 000b:trace:ole:ITypeLib2_Constructor_MSFT 0xe31180, TLB length = 4384
>
> trace (with OLE75/OLE76 and native stdole32.tlb copied to \windows\system):
>
> 000b:trace:ole:LoadTypeLib (L"stdole32.tlb",0x80d0dc)
> 000b:trace:ole:LoadTypeLibEx (L"stdole32.tlb",0,0x80d0dc)
> 000b:trace:ole:LoadTypeLibEx File L"C:\\windows\\system\\stdole32.tlb" index 1
> 000b:trace:ole:ITypeLib2_Constructor_SLTG 0x7e9602b0, TLB length = 4240
>
> Why do we use _SLTG in the first and last trace and _MSFT in the second?
>
> Cheers,
>
> Paul.

I have 3 native stdole files:

[paul(a)penguin tools]$ ll std*
-rw-rw-r--  1 paul paul 16896 Feb 21 14:39 stdole2.tlb
-rw-rw-r--  1 paul paul  7168 Feb 17 19:57 stdole32.tlb
-rw-rw-r--  1 paul paul  5472 Feb 21 16:48 stdole.tlb

`strings` show:

[paul(a)penguin tools]$ strings stdole2.tlb | grep -e MSFT -e SLTG
MSFT
[paul(a)penguin tools]$ strings stdole32.tlb | grep -e MSFT -e SLTG
SLTG
[paul(a)penguin tools]$ strings stdole.tlb | grep -e MSFT -e SLTG
SLTG

This explains the traces (a bit). But not why our stdole32.tlb has a
MSFT signature.

Cheers,

Paul.

[Huw D M Davies]

On Mon, Feb 21, 2005 at 04:57:05PM +0100, Paul Vriens wrote:
> On Mon, 2005-02-21 at 15:16, Paul Vriens wrote:
> > Hi (again),
> >
> > I've applied OLE#75 and OLE#76 and now I've something that doesn't look
> > right:
> >
> > trace (without OLE75/OLE76 and with native stdole32.tlb):
> >
> > 000b:trace:ole:LoadTypeLib (L"C:\\windows\\system\\stdole32.tlb",0xa9d0dc)
> > 000b:trace:ole:LoadTypeLibEx (L"C:\\windows\\system\\stdole32.tlb",0,0xa9d0dc)
> > 000b:trace:ole:LoadTypeLibEx File L"C:\\windows\\system\\stdole32.tlb" index 1
> > 000b:trace:ole:ITypeLib2_Constructor_SLTG 0x7e8702b0, TLB length = 4240
> >
> > trace (with OLE75/OLE76 and builtin stdole32.tlb):
> >
> > 000b:trace:ole:LoadTypeLib (L"stdole32.tlb",0x3dd0dc)
> > 000b:trace:ole:LoadTypeLibEx (L"stdole32.tlb",0,0x3dd0dc)
> > 000b:trace:ole:LoadTypeLibEx File L"stdole32.tlb" index 1
> > 000b:trace:ole:TLB_ReadTypeLib not found, trying to load L"stdole32.tlb" as library
> > 000b:trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\stdole32.tlb" : builtin
> > 000b:trace:ole:ITypeLib2_Constructor_MSFT 0xe31180, TLB length = 4384
> >
> > trace (with OLE75/OLE76 and native stdole32.tlb copied to \windows\system):
> >
> > 000b:trace:ole:LoadTypeLib (L"stdole32.tlb",0x80d0dc)
> > 000b:trace:ole:LoadTypeLibEx (L"stdole32.tlb",0,0x80d0dc)
> > 000b:trace:ole:LoadTypeLibEx File L"C:\\windows\\system\\stdole32.tlb" index 1
> > 000b:trace:ole:ITypeLib2_Constructor_SLTG 0x7e9602b0, TLB length = 4240
> >
> > Why do we use _SLTG in the first and last trace and _MSFT in the second?
> >
> > Cheers,
> >
> > Paul.
>
> I have 3 native stdole files:
>
> [paul(a)penguin tools]$ ll std*
> -rw-rw-r--  1 paul paul 16896 Feb 21 14:39 stdole2.tlb
> -rw-rw-r--  1 paul paul  7168 Feb 17 19:57 stdole32.tlb
> -rw-rw-r--  1 paul paul  5472 Feb 21 16:48 stdole.tlb
>
> `strings` show:
>
> [paul(a)penguin tools]$ strings stdole2.tlb | grep -e MSFT -e SLTG
> MSFT
> [paul(a)penguin tools]$ strings stdole32.tlb | grep -e MSFT -e SLTG
> SLTG
> [paul(a)penguin tools]$ strings stdole.tlb | grep -e MSFT -e SLTG
> SLTG
>
> This explains the traces (a bit). But not why our stdole32.tlb has a
> MSFT signature.

Becasue we only have typelib generation code for MSFT type typelibs.
The assumption is that no app will actually try to parse the typelib
itself so we're free to use either format.

Huw.
-- 
Huw Davies
huw(a)codeweavers.com