Outlook98 and winsock(?) troubles ...
Peter Lord
get Outlook running - without windows (installation from the CD) and
with windows (running from a pre-installed copy of Windows). I think
its best to keep the two discussion seperate ]
I have a pre-installed copy of Windows95 + Outlook98. Using "hallowine"
plus the default config file, Outlook98 goes quite a long way. I get a
pop-up box asking for my username and password and I can see OL
authenticating against the exchange server.... however, wine dies
suddently :-
.....
trace:winsock:fd_set_unimport
trace:winsock:WINSOCK_send (40a27600): socket 005b, ptr 40a2a128, length
128, flags 0
trace:winsock:WINSOCK_recv (40a27600): socket 005b, buf 40a29d10, len
512, flags 0
trace:winsock:WINSOCK_recv -> 119 bytes
trace:winsock:WINSOCK_send (40a27600): socket 005b, ptr 40a2a670, length
129, flags 0
trace:winsock:WINSOCK_send (40a27600): socket 005b, ptr 40a29d10, length
112, flags 0
trace:winsock:WINSOCK_recv (40a27600): socket 005b, buf 40a29f10, len
512, flags 0
trace:winsock:WINSOCK_recv -> 96 bytes
trace:winsock:WSOCK32_LibMain 0x42240000 0x3 (nil)
trace:winsock:WSOCK32_LibMain 0x42240000 0x2 (nil)
fixme:module:CreateProcessA (C:\WINDOWS\SYSTEM\MAPISP32.EXE,...):
DETACHED_PROCESS ignored
fixme:module:CreateProcessA (C:\WINDOWS\SYSTEM\MAPISP32.EXE,...):
NORMAL_PRIORITY_CLASS ignored
fixme:module:CreateProcessA (C:\WINDOWS\SYSTEM\MAPISP32.EXE,...):
CREATE_DEFAULT_ERROR_MODE ignored
fixme:profile:WritePrivateProfileSectionA WritePrivateProfileSection32A
empty stub
trace:winsock:WSAStartup16 verReq=101
trace:winsock:WSAStartup16 succeeded
trace:winsock:WINSOCK_socket (40a27600): af=6 type=2 protocol=1000
wine: select.c:39: register_select_user: Assertion `!users[user->fd]'
failed.
At this point wine exits (no debugger) with other wine processes still
running.
Any ideas / debug methods which may help ?
Many thanks,
Pete
Ove Kaaven
[...working winsock stuff...]
> trace:winsock:WSOCK32_LibMain 0x42240000 0x3 (nil)
> trace:winsock:WSOCK32_LibMain 0x42240000 0x2 (nil)
> fixme:module:CreateProcessA (C:\WINDOWS\SYSTEM\MAPISP32.EXE,...):
> DETACHED_PROCESS ignored
> fixme:module:CreateProcessA (C:\WINDOWS\SYSTEM\MAPISP32.EXE,...):
> NORMAL_PRIORITY_CLASS ignored
> fixme:module:CreateProcessA (C:\WINDOWS\SYSTEM\MAPISP32.EXE,...):
> CREATE_DEFAULT_ERROR_MODE ignored
> fixme:profile:WritePrivateProfileSectionA WritePrivateProfileSection32A
> empty stub
> trace:winsock:WSAStartup16 verReq=101
> trace:winsock:WSAStartup16 succeeded
I assume it spawned a new .exe file here, apparently MAPISP32
(the Mail API server?), so it's in a new independent handle space.
> trace:winsock:WINSOCK_socket (40a27600): af=6 type=2 protocol=1000
> wine: select.c:39: register_select_user: Assertion `!users[user->fd]'
> failed.
Even though the handle space changed, this really shouldn't happen
under any circumstances, and I can't see anywhere in sock.c that would
cause this. Maybe there's a bug elsewhere in the wineserver. Could
you add +server to your debugmsgs?
> At this point wine exits (no debugger) with other wine processes still
> running.
Yes, when the wineserver aborts abruptly (like for assertion failures),
the remaining wine clients aren't terminated. The internal debugger is
also only for the wine clients, not the wineserver.
(The wineserver is supposed to only administer things and such, not
actually perform a lot of duties, so it's supposed to be relatively
small and bugfree. Think of it as Wine's microkernel (um... NT?))
Peter Lord
Many thanks for your reply and useful info.
>
> > wine: select.c:39: register_select_user: Assertion `!users[user->fd]'
> > failed.
>
> Even though the handle space changed, this really shouldn't happen
> under any circumstances, and I can't see anywhere in sock.c that would
> cause this. Maybe there's a bug elsewhere in the wineserver. Could
> you add +server to your debugmsgs?
I added this in as you suggest, but no additional debug output (seems odd).
My startup line is now :-
wine -config /tmp/wineol.ini -winver win95 -managed -debugmsg
+winsock,+server "C:/Program Files/Microsoft Office/Office/OUTLOOK.EXE"
Is it possible that one of the forked off wine processes has crashed ? If
so, how can I tell ?
Ta
Pete
Ove Kaaven
> I added this in as you suggest, but no additional debug output (seems odd).
Hmm, seems that one of the recent changes to command-line-parsing order
forgot +server. Here's a patch for that; try again with it.
Index: wine/loader/main.c
===================================================================
RCS file: /home/wine/wine/loader/main.c,v
retrieving revision 1.50
diff -u -r1.50 main.c
--- wine/loader/main.c 1999/10/23 16:53:34 1.50
+++ wine/loader/main.c 1999/11/02 16:23:06
@@ -62,14 +62,14 @@
/* Create the initial process */
if (!PROCESS_Init()) return 0;
- /* Set server debug level */
- CLIENT_SetDebug( TRACE_ON(server) );
-
/* Initialize syslevel handling */
SYSLEVEL_Init();
/* Parse command line arguments */
MAIN_WineInit( argc, argv );
+
+ /* Set server debug level */
+ CLIENT_SetDebug( TRACE_ON(server) );
/* Load the configuration file */
if (!PROFILE_LoadWineIni()) return FALSE;
Peter Lord
> Peter Lord <peter...@ntl.com> writes:
>
> > I added this in as you suggest, but no additional debug output (seems odd).
>
> Hmm, seems that one of the recent changes to command-line-parsing order
> forgot +server. Here's a patch for that; try again with it.
Thanks for that, I applied the patch ... here are the last few lines :-
0843dbb0: create_semaphore( initial=00000000, max=00000001, inherit=0, name="" )
0843dbb0: create_semaphore() = 0 { handle=233 }
0843dbb0: create_mutex( owned=0, inherit=0,
name="5065746572204C6F7264245CFE6E6090D311932F0060080CBB45" )
0843dbb0: create_mutex() = 0 { handle=234 }
0843dbb0: select( count=1, flags=0, timeout=-1, handles={85} )
0843dbb0: select() = 0 { signaled=0 }
0843dbb0: release_mutex( handle=85 )
0843dbb0: release_mutex() = 0
0843dbb0: select( count=1, flags=0, timeout=-1, handles={85} )
0843dbb0: select() = 0 { signaled=0 }
0843dbb0: select( count=1, flags=4, timeout=0, handles={234} )
0843dbb0: select() = 0 { signaled=0 }
0843dbb0: release_mutex( handle=85 )
0843dbb0: release_mutex() = 0
0843dbb0: create_semaphore( initial=00000000, max=00000001, inherit=0, name="" )
0843dbb0: create_semaphore() = 0 { handle=235 }
trace:winsock:WSAStartup16 verReq=101
trace:winsock:WSAStartup16 succeeded
trace:winsock:WINSOCK_socket (40a27408): af=6 type=2 protocol=1000
0843dbb0: create_socket( access=c0100000, inherit=1, family=4, type=2,
protocol=1000 )
socket(4,2,1000)=-1
wine: select.c:39: register_select_user: Assertion `!users[user->fd]' failed.
I guess that the assert failed because the socket failed to be created. I read
the socket call as socket (PF_IPX, SOCK_DGRAM, 1000) - I couldn't track down
what 1000 might be. Note that I didn't install netware client when installing
this Win95 image, so I suspect the socket should fail.
Pete
Ove Kaaven
> trace:winsock:WINSOCK_socket (40a27408): af=6 type=2 protocol=1000
> 0843dbb0: create_socket( access=c0100000, inherit=1, family=4, type=2,
> protocol=1000 )
> socket(4,2,1000)=-1
> wine: select.c:39: register_select_user: Assertion `!users[user->fd]' failed.
>
>
> I guess that the assert failed because the socket failed to be created.
Oops. (This must be MS programming - never check for other errors than
user errors. That way if it crashes, it's always the user's fault...)
Well, here's the Winsock Service Pack:
Index: wine/server/sock.c
===================================================================
RCS file: /home/wine/wine/server/sock.c,v
retrieving revision 1.3
diff -u -r1.3 sock.c
--- wine/server/sock.c 1999/10/24 22:13:53 1.3
+++ wine/server/sock.c 1999/11/03 12:51:26
@@ -310,6 +310,11 @@
sock->event = NULL;
if (debug_level)
fprintf(stderr,"socket(%d,%d,%d)=%d\n",family,type,protocol,sock->select.fd);
+ if (sock->select.fd==-1) {
+ sock_set_error();
+ release_object( sock );
+ return NULL;
+ }
fcntl(sock->select.fd, F_SETFL, O_NONBLOCK); /* make socket nonblocking */
register_select_user( &sock->select );
sock_reselect( sock );
@@ -343,6 +348,7 @@
}
if (!(acceptsock = alloc_object( &sock_ops )))
{
+ close( acceptfd );
release_object( sock );
return NULL;
}
Peter Lord
> Peter Lord <peter...@ntl.com> writes:
>
> > trace:winsock:WINSOCK_socket (40a27408): af=6 type=2 protocol=1000
> > 0843dbb0: create_socket( access=c0100000, inherit=1, family=4, type=2,
> > protocol=1000 )
> > socket(4,2,1000)=-1
> > wine: select.c:39: register_select_user: Assertion `!users[user->fd]' failed.
> >
> >
> > I guess that the assert failed because the socket failed to be created.
>
> Oops. (This must be MS programming - never check for other errors than
> user errors. That way if it crashes, it's always the user's fault...)
> Well, here's the Winsock Service Pack:
Many thanks for this ... a bit further forward I think, although still failing. I now
get :-
trace:winsock:WSAStartup16 verReq=101
trace:winsock:WSAStartup16 succeeded
trace:winsock:WINSOCK_socket (40a27408): af=6 type=2 protocol=1000
0843dbd0: create_socket( access=c0100000, inherit=1, family=4, type=2, protocol=1000 )
socket(4,2,1000)=-1
wine: select.c:49: unregister_select_user: Assertion `users[user->fd] == user' failed.
I guess that there needs to be another similar patch ... I've tried looking for it
myself, but I can't figure out the program flow !!
Cheers,
Pete
Ove Kaaven
> Many thanks for this ... a bit further forward I think, although still failing. I now
> get :-
>
> trace:winsock:WSAStartup16 verReq=101
> trace:winsock:WSAStartup16 succeeded
> trace:winsock:WINSOCK_socket (40a27408): af=6 type=2 protocol=1000
> 0843dbd0: create_socket( access=c0100000, inherit=1, family=4, type=2, protocol=1000 )
> socket(4,2,1000)=-1
> wine: select.c:49: unregister_select_user: Assertion `users[user->fd] == user' failed.
>
> I guess that there needs to be another similar patch ... I've tried looking for it
> myself, but I can't figure out the program flow !!
Bah. I forgot that the release_object() would indirectly call sock_destroy(),
which calls unregister_select_user() with, yeah, the invalid fd. Hmm. I wonder
if it'll be easiest to change sock_destroy, or the order of events (call
socket() *first* and alloc_object *later*. Perhaps the latter would be
best...
Here's Service Pack 2 (reinstall (remove Service Pack 1) before applying)
Index: wine/server/sock.c
===================================================================
RCS file: /home/wine/wine/server/sock.c,v
retrieving revision 1.3
diff -u -r1.3 sock.c
--- wine/server/sock.c 1999/10/24 22:13:53 1.3
+++ wine/server/sock.c 1999/11/04 10:45:07
@@ -297,10 +297,19 @@
static struct object *create_socket( int family, int type, int protocol )
{
struct sock *sock;
+ int sockfd;
+ sockfd = socket( family, type, protocol );
+ if (debug_level)
+ fprintf(stderr,"socket(%d,%d,%d)=%d\n",family,type,protocol,sockfd);
+ if (sockfd == -1) {
+ sock_set_error();
+ return NULL;
+ }
+ fcntl(sockfd, F_SETFL, O_NONBLOCK); /* make socket nonblocking */
if (!(sock = alloc_object( &sock_ops )))
return NULL;
- sock->select.fd = socket(family,type,protocol);
+ sock->select.fd = sockfd;
sock->select.func = sock_select_event;
sock->select.private = sock;
sock->state = (type!=SOCK_STREAM) ? WS_FD_READ|WS_FD_WRITE : 0;
@@ -308,9 +317,6 @@
sock->hmask = 0;
sock->pmask = 0;
sock->event = NULL;
- if (debug_level)
- fprintf(stderr,"socket(%d,%d,%d)=%d\n",family,type,protocol,sock->select.fd);
- fcntl(sock->select.fd, F_SETFL, O_NONBLOCK); /* make socket nonblocking */
register_select_user( &sock->select );
sock_reselect( sock );
clear_error();
@@ -343,6 +349,7 @@
Peter Lord
>
> Bah. I forgot that the release_object() would indirectly call sock_destroy(),
> which calls unregister_select_user() with, yeah, the invalid fd. Hmm. I wonder
> if it'll be easiest to change sock_destroy, or the order of events (call
> socket() *first* and alloc_object *later*. Perhaps the latter would be
> best...
>
> Here's Service Pack 2 (reinstall (remove Service Pack 1) before applying)
Wow.... that did the trick. This part of the trace is now :-
trace:winsock:WINSOCK_socket (40a27408): af=6 type=2 protocol=1000
0843dc10: create_socket( access=c0100000, inherit=1, family=4, type=2, protocol=1000 )
socket(4,2,1000)=-1
0843dc10: create_socket() = 10022 { handle=-1 }
warn:winsock:WINSOCK_socket failed!
trace:winsock:WINSOCK_gethostname (40a27408): name , len 260
trace:winsock:WINSOCK_gethostbyname plordnote
trace:winsock:WINSOCK_socket (40a27408): af=2 type=2 protocol=17
0843dc10: create_socket( access=c0100000, inherit=1, family=2, type=2, protocol=17 )
socket(2,2,17)=23
So I guess OL is trying IPX (which fails) and then IP which works (makes sense).
OL then continues until :-
Unhandled exception: page fault on write access to 0xefefeff7 in 32-bit code
(0x0809766f).
The traceback is :-
Backtrace:
=>0 0x0809766f (HEAP_CreateFreeBlock+0x7b [heap.c:345]) (ebp=409ff41c)
1 0x0809770f (HEAP_MakeInUseBlockFree+0x43(subheap=0x40a20000, pArena=0x40a2b238)
[heap.c:393]) (ebp=409ff43c)
2 0x080987c4 (HeapFree+0x124(heap=0x40a20000, flags=0x0, ptr=0x40a2b244) [heap.c:1039])
(ebp=409ff464)
3 0x70101ccb (RPCRT4.dll.RpcServerRegisterIfEx+0x2ac) (ebp=42a60c14)
4 0x42a60d08 (MSNSSPC.dll..reloc+0x562d08) (ebp=42a60cb8)
5 0x00637072 (+0x632896) (ebp=6c61636e)
*** Invalid address 0x6c61636e (ole32.dll..reloc+0x666336e)
0x0809766f (HEAP_CreateFreeBlock+0x7b [heap.c:345]): movl %eax,0x8(%edx)
I guess I'm into different problems now :-(
Pete
Uwe Bonnes
: Ove Kaaven wrote:
: Backtrace:
: =>0 0x0809766f (HEAP_CreateFreeBlock+0x7b [heap.c:345]) (ebp=409ff41c)
: 1 0x0809770f (HEAP_MakeInUseBlockFree+0x43(subheap=0x40a20000,
pArena=0x40a2b238)
: [heap.c:393]) (ebp=409ff43c)
: 2 0x080987c4 (HeapFree+0x124(heap=0x40a20000, flags=0x0, ptr=0x40a2b244) [heap.c:1039])
: (ebp=409ff464)
: 3 0x70101ccb (RPCRT4.dll.RpcServerRegisterIfEx+0x2ac) (ebp=42a60c14)
: 4 0x42a60d08 (MSNSSPC.dll..reloc+0x562d08) (ebp=42a60cb8)
: 5 0x00637072 (+0x632896) (ebp=6c61636e)
: *** Invalid address 0x6c61636e (ole32.dll..reloc+0x666336e)
: 0x0809766f (HEAP_CreateFreeBlock+0x7b [heap.c:345]): movl
%eax,0x8(%edx)
: I guess I'm into different problems now :-(
Keep om debugging :-)
Now run with -debugmsg +relay,+snoop and look if you get the error in the
same place. If yes, look at the last calls or before where the NULL pointer
or bad heap got from. -debugmsg +relay,+snoop,+heap might help more, but
may get you a huge log.
In some situations I had 100MByte++ logs.
Bye
--
Uwe Bonnes b...@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Peter Lord
>
> Keep om debugging :-)
>
> Now run with -debugmsg +relay,+snoop and look if you get the error in the
> same place. If yes, look at the last calls or before where the NULL pointer
> or bad heap got from. -debugmsg +relay,+snoop,+heap might help more, but
> may get you a huge log.
> In some situations I had 100MByte++ logs.
>
okay ... I'm still going!
Firstly the error is in the same place. Running with -debugmsg +relay,+snoop I get :-
.....
Ret NTDLL.518: RtlUnwind() retval=00000000 ret=7800ca38 fs=0237
eax=00000000 ebx=40a3f5b8 ecx=c0000005 edx=40a3dd44 esi=00000000 edi=6f741358
ebp=40a3dd28 esp=40a3dd18 ds=002b es=002b gs=0000 flags=00000202
Call RPCRT4.261: RpcBindingFree(<unknown, check return>) ret=6f7586ca fs=0237
Call KERNEL32.463: HeapFree(40a60000,00000000,40a6c194) ret=70101ccb fs=0237
Ret KERNEL32.463: HeapFree() retval=00000001 ret=70101ccb fs=0237
Call KERNEL32.463: HeapFree(40a60000,00000000,40a6c1b8) ret=70101ccb fs=0237
Ret KERNEL32.463: HeapFree() retval=00000001 ret=70101ccb fs=0237
Call KERNEL32.463: HeapFree(40a60000,00000000,40a6c248) ret=70101ccb fs=0237
Ret KERNEL32.463: HeapFree() retval=00000001 ret=70101ccb fs=0237
Call KERNEL32.463: HeapFree(40a60000,00000000,40a6c164) ret=70101ccb fs=0237
Ret KERNEL32.463: HeapFree() retval=00000001 ret=70101ccb fs=0237
Call KERNEL32.185: DeleteCriticalSection(40a6c2c0) ret=701032f1 fs=0237
Ret KERNEL32.185: DeleteCriticalSection() retval=00000001 ret=701032f1 fs=0237
Call KERNEL32.463: HeapFree(40a60000,00000000,40a6c26c) ret=70101ccb fs=0237
Call MSVCRT.199: _except_handler3(<unknown, check return>) ret=08061daf fs=0237
Ret MSVCRT.199: _except_handler3() retval = 00000001 ret=08061daf fs=0237
Call KERNEL32.702: UnhandledExceptionFilter(40a3f0ac) ret=3000269f fs=0237
Call KERNEL32.477: IsBadCodePtr(7fd49e61) ret=7d569401 fs=0237
Ret KERNEL32.477: IsBadCodePtr() retval=00000000 ret=7d569401 fs=0237
Call KERNEL32.477: IsBadCodePtr(6e743d71) ret=7fd43046 fs=0237
Ret KERNEL32.477: IsBadCodePtr() retval=00000000 ret=7fd43046 fs=0237
Unhandled exception: page fault on write access to 0xefefeff7 in 32-bit code (0x0809766f).
Does this mean we are in RPCRT4 and KERNEL32.463 ? So I'm getting a heapfree exception ?
If I add on +heap, I get :-
Ret NTDLL.518: RtlUnwind() retval=00000000 ret=7800ca38 fs=0237
eax=00000000 ebx=40a3f5b8 ecx=c0000005 edx=40a3dd44 esi=00000000 edi=6f741358
ebp=40a3dd28 esp=40a3dd18 ds=002b es=002b gs=0000 flags=00000202
Call RPCRT4.261: RpcBindingFree(<unknown, check return>trace:heap:HeapAlloc
(40450000,00000002,00000040): returning 404a5eb0) ret=6f7586ca fs=0237
Call KERNEL32.463: HeapFree(40a60000,00000000,40a6c1e4) ret=70101ccb fs=0237
err:heap:HEAP_ValidateFreeArena Heap 40a60000: prev arena 40a6db00 invalid for 40a669f8
Heap: 40a60000
Next: 00000000 Sub-heaps: 40a60000
Free lists:
Block Stat Size Id
40a60024 free 00000001 0000 prev=40a65de0 next=40a6c658
..... [tuns of heap stuff deleted]
Call MSVCRT.199: _except_handler3(<unknown, check return>trace:heap:HeapAlloc
(40450000,00000002,00000040): returning 404a5efc) ret=08061daf fs=0237
Ret MSVCRT.199: _except_handler3() retval = 00000001 ret=08061daf fs=0237
trace:heap:HeapFree (40450000,00000002,404a5efc): returning TRUE
Call KERNEL32.702: UnhandledExceptionFilter(40a3f09c) ret=3000269f fs=0237
Call KERNEL32.477: IsBadCodePtr(7fd49e61) ret=7d569401 fs=0237
Ret KERNEL32.477: IsBadCodePtr() retval=00000000 ret=7d569401 fs=0237
Call KERNEL32.477: IsBadCodePtr(6e743d71) ret=7fd43046 fs=0237
Ret KERNEL32.477: IsBadCodePtr() retval=00000000 ret=7fd43046 fs=0237
Unhandled exception: page fault on read access to 0x315346b4 in 32-bit code (0x080972a0).
Pete
Jürgen Schmied
>Call MSVCRT.199: _except_handler3(<unknown, check return>) ret=08061daf fs=0237
>Ret MSVCRT.199: _except_handler3() retval = 00000001 ret=08061daf fs=0237
>Call KERNEL32.702: UnhandledExceptionFilter(40a3f0ac) ret=3000269f fs=0237
>Call KERNEL32.477: IsBadCodePtr(7fd49e61) ret=7d569401 fs=0237
> Ret KERNEL32.477: IsBadCodePtr() retval=00000000 ret=7d569401 fs=0237
> Call KERNEL32.477: IsBadCodePtr(6e743d71) ret=7fd43046 fs=0237
> Ret KERNEL32.477: IsBadCodePtr() retval=00000000 ret=7fd43046 fs=0237
> Unhandled exception: page fault on write access to 0xefefeff7 in 32-bit code (0x0809766f).
error (HeapValidate) points in this direction too. A corrupted linked list...
>Does this mean we are in RPCRT4 and KERNEL32.463 ?
yes.
> Call KERNEL32.463: HeapFree(40a60000,00000000,40a6c1e4) ret=70101ccb fs=0237
> err:heap:HEAP_ValidateFreeArena Heap 40a60000: prev arena 40a6db00 invalid for 40a669f8
> Heap: 40a60000
> Next: 00000000 Sub-heaps: 40a60000
> Free lists:
> Block Stat Size Id
> 40a60024 free 00000001 0000 prev=40a65de0 next=40a6c658
... looks like a buffer over/under flow. Nearly impossible to debug such things remote and
mostly extreamly hard to find. It can have happend _anywhere_ before these lines.
;-((
juergen
------
Home: ds9.net/schmied
Peter Lord
>
> ... looks like a buffer over/under flow. Nearly impossible to debug such things remote and
> mostly extreamly hard to find. It can have happend _anywhere_ before these lines.
> ;-((
Thanks for the info ....
One thing I did notice, that if I run with "-dll advapi32=n" OL does get further, and gets to a
point where it seems to be having trouble connecting to the server :-
fixme:winsock:convert_sockopt Unknown IPPROTO_TCP optname 8
fixme:winsock:convert_sockopt Unknown IPPROTO_TCP optname 8
fixme:win32:DeviceIoControl Unimplemented control 107 for VxD device VRedir
fixme:win32:WaitNamedPipeA \\EXCH_CTL2\pipe\epmapper 0x00000000
[long wait]
Is there anyway forward now ? I was thinking if anyone has some time to look at this in more
detail, I can take the time to create a minimum set of files which shows this problem and send to
the interested party .....
Pete
Uwe Bonnes
: "Jürgen Schmied" wrote:
: One thing I did notice, that if I run with "-dll advapi32=n" OL does get
: further, and gets to a
: point where it seems to be having trouble connecting to the server :-
For the sake of debugging wine:
Can you find out the ADVAPI32 call, that wine's advapi32 does in another way
than the native one?
Peter Lord
> Peter Lord <peter...@ntl.com> wrote:
> : "Jürgen Schmied" wrote:
>
> : One thing I did notice, that if I run with "-dll advapi32=n" OL does get
> : further, and gets to a
> : point where it seems to be having trouble connecting to the server :-
>
> For the sake of debugging wine:
>
> Can you find out the ADVAPI32 call, that wine's advapi32 does in another way
> than the native one?
>
Yes, I would certainly like to contribute this info. What is the best method
do you think? I though of running with +relay in both cases and trying a diff
between the two debugging outputs ....
Uwe Bonnes
: Uwe Bonnes wrote:
: diff the two debugging outputs ....
Well,
human creativity in problem solving is probably asked here.
I would first try
... -dll advapi32=n -debugmsg +snoop=ADVAPI32
and
... -dll advapi32=b -debugmsg +relay=ADVAPI32
Bye
Jürgen Schmied
> [long wait]
If I remember right its possible somehow to choose the protocoll exchange uses.
(Don't remenber where but at least for exchange 5 there was a generator for
generating a customized setup. Think it was in there.).
Tcp/IP might be the only chance...
bye
juergen
------
Home: ds9.net/schmied
Peter Lord
Doesn't sound too hopefull - I don't have access to the servers here :-( I'll check
this out further though,
Pete
Peter Lord
>
>
> I would first try
>
> ... -dll advapi32=n -debugmsg +snoop=ADVAPI32
> and
> ... -dll advapi32=b -debugmsg +relay=ADVAPI32
Damm ... when I turn on any debugging in this way, outlook does't crash (just gets
to the point waiting for a named pipe). To summarise :-
no options - heap overrun/underrun
"-dll advapi32=n" - no crash, gets to named pipe wait
"-dll advapi32=b" - heap overrun/underrun
"-dll advapi32=b -debugmsg +relay=ADVAPI32" - no crash, gets to named pipe wait
Pete
Uwe Bonnes
: Uwe Bonnes wrote:
: no options - heap overrun/underrun
: "-dll advapi32=n" - no crash, gets to named pipe wait
: "-dll advapi32=b" - heap overrun/underrun
: "-dll advapi32=b -debugmsg +relay=ADVAPI32" - no crash, gets to named pipe wait
Hallo,
[just a warning: At the moment I am good a sending people astray ( look at
recent discussions on wine-devel...) ]
I think I remember that different behaviour with and without "-debugmsg
+relay" is often a sign for some API definition in Wine being wrong. Either
something is defined WINAPI while it is really WINAPIV or vice versa, or
arguments to some function don't are right in size.
If you still want to debug, I propose you try
"-dll advapi32=b -debugmsg +relay=ADVAPI32,+heap" and look if you can repeat
the error in that case. If you can, check the API relay calls for their
definition.
Bye