Re: Crash on glBegin() (Was: Help with debugging needed)
Hi, On Tue, Aug 23, 2005 at 12:35:16PM +, Stefan Dösinger wrote: I'll try to reproduce the behaviour and write a small test for this problem and the reference counting issue. However, this may take some time... Could you do a +ddraw,+tid trace and check that all DirectX calls are done from the same thread ? If not, Wine is doing bad stuff that may lead to crashes in the GL drivers depending on the way they handle TLS and then your problem is a 'classical' one (for which the solution is still in the 'need to be done one day' phase :-) ). As far as I can tell from a quick look, no. All ddraw calls are done from the same thread, there are only a few imm32 calls from another thread. Empire Earth uses at least 2 threads, one for the sound, and another one for the rest. Perhaps there's also a third one for the DirectMusic stuff, which I have disabled in the game's config. I have noticed that it creates multiple DirectDraw and Direct3D devices, some of them are freed, re-created and freed again. At the time of the crash due to reference counting, there are at least 2 DirectDraw and 2 Direct3D objects. Is this going to work? I'll try to solve the reference counting problem first, because my first patch only solved the symptom, but not the cause, and I'm not sure if there are no connections between the 2 crashes. Do you still want to see a +ddraw,+tid trace? I can upload one to my homepage. Stefan
Re: Crash on glBegin() (Was: Help with debugging needed)
As far as I can tell from a quick look, no. All ddraw calls are done from the same thread, there are only a few imm32 calls from another thread. OK, a shame :-) I have noticed that it creates multiple DirectDraw and Direct3D devices, some of them are freed, re-created and freed again. At the time of the crash due to reference counting, there are at least 2 DirectDraw and 2 Direct3D objects. Is this going to work? Well, there should be no issue with that except if there is some issue in the GL drivers about an application having multiple contexts created at the same time? Do you still want to see a +ddraw,+tid trace? I can upload one to my homepage. Well, if it's not multithreaded in DDraw, no need. I still have to look at your other trace with the refcounting issue to try to see where the problem lies. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Crash on glBegin() (Was: Help with debugging needed)
On Tue, Aug 23, 2005 at 12:35:16PM +, Stefan Dösinger wrote: I'll try to reproduce the behaviour and write a small test for this problem and the reference counting issue. However, this may take some time... Could you do a +ddraw,+tid trace and check that all DirectX calls are done from the same thread ? If not, Wine is doing bad stuff that may lead to crashes in the GL drivers depending on the way they handle TLS and then your problem is a 'classical' one (for which the solution is still in the 'need to be done one day' phase :-) ). Lionel (back from vacation so a bit 'mail-lagged' :-) ) -- Lionel Ulmer - http://www.bbrox.org/
Re: Crash on glBegin() (Was: Help with debugging needed)
Am Montag, 22. August 2005 22:16 schrieb James Liggett: Hi Stefan, Now I've run into the next problem: Any call to glBegin(GL_Something) crashes in the libs of my OpenGL driver(ATI fglrx) due to some NULL pointer access[1]. If I disable Hardware Acceleration, the crash doesn't occur and Empire Earth starts up to the Main Menu more or less successfully: It only shows a black screen, but it reacts to keypresses(Sounds are playing, I can take screenshots with the in-game Screen Shot Funktionality[2]. A +ddraw log can be found at http://www.doesi.gmxhome.de/ee.out.bz2 Perhaps you should try upgrading your fglrx drivers. They released new ones a few days ago. I've seen the new driver yesterday, and I'll update it ASAP, but I don't expect it to fix this issue. I'll try to reproduce the behaviour and write a small test for this problem and the reference counting issue. However, this may take some time... Stefan
Re: Help with debugging needed
Hi,
Could you put the +ddraw trace somewhere on the web ? This suspiciously
looks like a reference counting issue either in the application or in the
Wine code.
It looks to me that Empire Earth accidentally frees the DirectDraw Interface
it's working with. During my look at the ddraw code, I've stubled accross
this thing in DDRAW_Create:
{
...
driver = DDRAW_FindDriver(lpGUID);
if (driver == NULL) return DDERR_INVALIDDIRECTDRAWGUID;
hr = driver-create(lpGUID, pDD, pUnkOuter, ex);
if (FAILED(hr)) return hr;
hr = IDirectDraw7_QueryInterface(pDD, iid, lplpDD);
IDirectDraw7_Release(pDD); -- Is this correct???
return hr;
}
I haven't found any useable Documentation on MSDN, because it's all archived
content. But this Release Call seems odd to me. If I remove this call, Empire
Earth continues loading and bails out on some string operation, which I
haven't investigated yet.
Stefan
Re: Help with debugging needed
Hi, That thing gets more and more interesting: I was mislead by the belief that 'next' would behave as 'nexti' at the end of the known C code. But obviosly it doesn't. Well, Empire Earth doesn't crash on return from Main_DirectDraw_Release, but quite a bit later in its own code. It tries to call Main_DirectDrawSurfaceRelease for an allready freed surface: From the crash dump: First chance exception: page fault on read access to 0x in 32-bit code (0x). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP: ESP:7fc1fc58 EBP:7f2703e0 EFLAGS:00210293( - 00 RISA1C) EAX:7fe049f0 EBX:0001 ECX:7fe01b38 EDX:7803a11c ESI:7f288aa0 EDI:7f288acc Stack dump: 0x7fc1fc58: 7dbbd6d7 7fe049f0 7f288aa0 7f2703e0 0x7fc1fc68: 0001 7dbb1c20 7dbc59b4 0x7fc1fc78: 7f9f24fc 0001 7fa24015 7dbc5998 0x7fc1fc88: 7fa23451 7dbc5998 7f270838 0x7fc1fc98: 0002 7dbb9a14 7fa6bda1 0x7fc1fca8: 7fc1fd04 0052ba8b 5c575f20 Backtrace: =1 0x (0x7f2703e0) 2 0x (0x) 0x: addb%al,0x0(%eax) The surface to to release is in %eax and the 2nd element on the stack: 7fe049f0. From the log, a few lines before the crash: warn:ddraw:Main_DirectDrawSurface_ForceDestroy destroying surface 0x7fe049f0 with refcnt 1 The address of the function is taken from the surface structur and now points to 0x. (I do not expect a reply to this mail. I write it for a few reasons: *Someone might have seen something like this allready *Someone(maybe I) might search the archives sometimes and find this information usefull. If I shouldn't do so, just tell me)
Re: Help with debugging needed
Well, Empire Earth doesn't crash on return from Main_DirectDraw_Release, but quite a bit later in its own code. It tries to call Main_DirectDrawSurfaceRelease for an allready freed surface: From the crash dump: Could you put the +ddraw trace somewhere on the web ? This suspiciously looks like a reference counting issue either in the application or in the Wine code. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Help with debugging needed
Am Montag, 15. August 2005 17:07 schrieb Lionel Ulmer: Well, Empire Earth doesn't crash on return from Main_DirectDraw_Release, but quite a bit later in its own code. It tries to call Main_DirectDrawSurfaceRelease for an allready freed surface: From the crash dump: Could you put the +ddraw trace somewhere on the web ? This suspiciously looks like a reference counting issue either in the application or in the Wine code. Sure. The log can be found at www.doesi.gmxhome.de/ee-ddraw.log.gz (38KB) Stefan
Re: Help with debugging needed
Am Montag, 15. August 2005 17:07 schrieb Lionel Ulmer: Well, Empire Earth doesn't crash on return from Main_DirectDraw_Release, but quite a bit later in its own code. It tries to call Main_DirectDrawSurfaceRelease for an allready freed surface: From the crash dump: Could you put the +ddraw trace somewhere on the web ? This suspiciously looks like a reference counting issue either in the application or in the Wine code. Oh, I forgot to add that I've done a little change to the ddraw code. Empire Earth calls Main_DirectDraw_SetCooperativeLevel with cooplevel == DDSCL_SETFOCUSWINDOW and expects a successfull result. I don't think that this is related to the problem. I've also modified dlls/ntdll/heap.c to allways fill freed heap areas with 0x. Stefan Index: dlls/ddraw/ddraw_main.c === RCS file: /home/wine/wine/dlls/ddraw/ddraw_main.c,v retrieving revision 1.8 diff -u -r1.8 ddraw_main.c --- dlls/ddraw/ddraw_main.c 26 Jul 2005 20:10:51 - 1.8 +++ dlls/ddraw/ddraw_main.c 15 Aug 2005 17:18:55 - @@ -1120,6 +1120,7 @@ return DDERR_HWNDALREADYSET; */ +if(cooplevel == DDSCL_SETFOCUSWINDOW) return DD_OK; if (!(cooplevel (DDSCL_EXCLUSIVE|DDSCL_NORMAL))) return DDERR_INVALIDPARAMS;
Re: Help with debugging needed
Hi, So my questions are: *Am I right with my suspection that the problems are caused by a incorrect return? It's possible. I'm working on a problem like that with palm desktop. But you won't know until you debug it :) It could be nasty to fix though. I was lucky with setting a brakepoint in the wine code. The crash happens in the DDraw implementation. The return from Main_DirectDraw_Release(ddraw_main.c:154) leads to a random adress. The call which leads to this is HeapFree(GetProcessHeap(), 0, This); in Main_DirectDrawSurface_Destroy, surface_main.c:154. If I comment out this call, Empire Earth continues loading and crashes more or less randomly at some later points. I've edited the IDirectDrawSurfaceImpl structure and added a 2048 byte block at the beginning and the end. This makes the crashes reliable: With the HeapFree call, the ret jumps to NULL, and without the call Empire Earth crashes little later. This looks like a really nasty heap corruption to me, and I'm afraid it's beyond my knowledge. Can anyone of the ddraw/d3d people help me? *How can I get a disassembly of Low-Level [EMAIL PROTECTED]@@UAEJXZ or simmilar functions. I didn't find this symbol. If I had to guess, I'd say these functions are in the game itself, most likely in one or more DLLs. Your best bet here is to use a good disassembler. My personal favorite is IDA. You can find a demo version here: http://www.datarescue.be/downloaddemo.htm. This version works just fine for this sort of thing. Yes it's a part of the game in a Dll called low-level engine.dll. The IDA disassembler looks really great, I'm considering ordering it. But it's quite expensive. Thanks for your help so far, Stefan
Re: Help with debugging needed
This looks like a really nasty heap corruption to me, and I'm afraid it's beyond my knowledge. Can anyone of the ddraw/d3d people help me? I think best would a +ddraw,+heap,+relay,+tid,+seh trace to be able to see where the corruption may occur. And it's not because it crashes into DDraw code that it's DDraw responsible for it :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Help with debugging needed
Am Samstag, 13. August 2005 19:34 schrieb Lionel Ulmer: This looks like a really nasty heap corruption to me, and I'm afraid it's beyond my knowledge. Can anyone of the ddraw/d3d people help me? I think best would a +ddraw,+heap,+relay,+tid,+seh trace to be able to see where the corruption may occur. And it's not because it crashes into DDraw code that it's DDraw responsible for it :-) I've made a +ddraw,+heap,+relay,+tid,+snoop tray long ago, and it didn't bring up anything usefull to me. I'll have another look and report back. I indeed was in doubt that ddraw or dinput are causing the problem, and I didn't find anything wrong in the DDraw code. Well, I'll see. BTW, Empire Earth crashes in exactly the same way in Cedega, where I expect the DirectX implementation to be quite different. Stefan
Re: Help with debugging needed
Am Samstag, 13. August 2005 19:34 schrieb Lionel Ulmer: This looks like a really nasty heap corruption to me, and I'm afraid it's beyond my knowledge. Can anyone of the ddraw/d3d people help me? I think best would a +ddraw,+heap,+relay,+tid,+seh trace to be able to see where the corruption may occur. And it's not because it crashes into DDraw code that it's DDraw responsible for it :-) This is interesting: Setting the +heap trace flag sets the bad address realiably to 0x(without my changes to DDraw). Does this say anything? Stefan
Re: Help with debugging needed
Hi, On Sat, Aug 13, 2005 at 10:35:34PM +, Stefan Dösinger wrote: Am Samstag, 13. August 2005 19:34 schrieb Lionel Ulmer: This looks like a really nasty heap corruption to me, and I'm afraid it's beyond my knowledge. Can anyone of the ddraw/d3d people help me? I think best would a +ddraw,+heap,+relay,+tid,+seh trace to be able to see where the corruption may occur. And it's not because it crashes into DDraw code that it's DDraw responsible for it :-) This is interesting: Setting the +heap trace flag sets the bad address realiably to 0x(without my changes to DDraw). Does this say anything? dlls/ntdll/heap.c:#define ARENA_FREE_FILLER 0xaa I'd guess this is an adress in an area that's actually gotten freed. Andreas -- No programming skills!? Why not help translate many Linux applications! https://launchpad.ubuntu.com/rosetta
Re: Help with debugging needed
On Sat, 2005-08-13 at 22:35 +, Stefan Dösinger wrote: Am Samstag, 13. August 2005 19:34 schrieb Lionel Ulmer: This looks like a really nasty heap corruption to me, and I'm afraid it's beyond my knowledge. Can anyone of the ddraw/d3d people help me? I think best would a +ddraw,+heap,+relay,+tid,+seh trace to be able to see where the corruption may occur. And it's not because it crashes into DDraw code that it's DDraw responsible for it :-) This is interesting: Setting the +heap trace flag sets the bad address realiably to 0x(without my changes to DDraw). Does this say anything? Looks like an uninitialized value to me. I've seen similar cases like that, and that's what it was. Stefan James
Re: Help with debugging needed
On Sat, 2005-08-13 at 22:15 +, Stefan Dösinger wrote: I indeed was in doubt that ddraw or dinput are causing the problem, and I didn't find anything wrong in the DDraw code. Well, I'll see. BTW, Empire Earth crashes in exactly the same way in Cedega, where I expect the DirectX implementation to be quite different. That's not too surprising. I agree with your theory that ddraw/dinput aren't the problem. It probably has to do with some internal heap function, maybe some kind of buffer overrun somewhere. And since Cedega is basically a really old version of wine with a bunch of half-baked DX hacks in it, I would expect the crash to happen there as well. Good luck finding the cause though. ;-) Stefan James
Help with debugging needed
Hello, I am trying(once again) to get Empire Earth [1] running with wine. After solving a few problems[2], I've run into a strange access violation crash. It looks like a buffer overrun, followed by a return to an invalid adress. A +relay,+snoop trace gives this: ... 0009:CALL Low-Level [EMAIL PROTECTED]@@UAEJXZ() ret=7e2b9a14 0009:CALL Low-Level [EMAIL PROTECTED]@@QAEXXZ() ret=7e2bd6c5 0009:RET Low-Level [EMAIL PROTECTED]@@QAEXXZ() retval=7f24fa70 ret=7e2bd6c5 0009:Call ntdll.RtlEnterCriticalSection(7f074a40) ret=7f0294c5 0009:Ret ntdll.RtlEnterCriticalSection() retval= ret=7f0294c5 0009:Call ntdll.RtlLeaveCriticalSection(7f074a40) ret=7f029506 0009:Ret ntdll.RtlLeaveCriticalSection() retval= ret=7f029506 0009:CALL MSVCRT._except_handler3(unknown, check return) ret=7beb649b 0009:CALL MSVCRT._XcptFilter(unknown, check return) ret=00665947 0009:Call kernel32.GetLastError() ret=7800385f 0009:Ret kernel32.GetLastError() retval=05b4 ret=7800385f 0009:Call kernel32.TlsGetValue() ret=7800386d 0009:Ret kernel32.TlsGetValue() retval=7f180f80 ret=7800386d 0009:Call kernel32.SetLastError(05b4) ret=7800387e 0009:Ret kernel32.SetLastError() retval=05b4 ret=7800387e 0009:Call kernel32.UnhandledExceptionFilter(7fc2f81c) ret=7800ed71 0009:Call ntdll.NtQueryVirtualMemory(,9803a11c,,7fc2f6e8,001c,7fc2f6a8) ret=7fd1aae1 0009:Ret ntdll.NtQueryVirtualMemory() retval= ret=7fd1aae1 0009:Call kernel32.IsBadCodePtr(7800add3) ret=22d2b743 0009:Ret kernel32.IsBadCodePtr() retval= ret=22d2b743 0009:Call ntdll.NtCreateEvent(7fc2f6e8,001f0003,7fc2f6ec,0001,) ret=7fccb9b9 0009:Ret ntdll.NtCreateEvent() retval= ret=7fccb9b9 wine: Unhandled exception (thread 0009), starting debugger... ... The crash messages look a little bit different every time, with illegal instructions / access violations or even a Segmentation Fault without starting winedbg at various addreses(Attached file crashes). On very rare occasions, this crash doesn't occur, and the game continues to load and crashes later in some ddraw function. Instead of crashing it complains about a corrupted heap: err:heap:HEAP_ValidateInUseArena Heap 0x7fd8: prev arena 0x7fe01640 is not prev for in-use 0x7fe01cb0 I've looked at a +heap trace, but I couldn't find anything usefull. (See ee-nocrash for a log). I've also attached a normal log without any special debug flags set(ee-normal.log.gz). I've added a few ERR statements for testing in some functions. So my questions are: *Am I right with my suspection that the problems are caused by a incorrect return? *How can I get a disassembly of Low-Level [EMAIL PROTECTED]@@UAEJXZ or simmilar functions. I didn't find this symbol. Thanks for your help, Stefan Dösinger [1] A demo is available at http://www.vugames.de/scripts/download.aspx?content=4id=53721nf=21url=ftp://downloads.vu-games.com/pub/empire%20earth/demos/Empire_earth_EN.exe, but I haven't checked wheter it produces the same results. [2] Other users reported a msvc runtime error, apparently caused by an error returned by Main_DirectDraw_SetCooperativeLevel. EE calls this function with cooplevel == DDSCL_SETFOCUSWINDOW. I made the function simply return DD_OK in this case. Furthermore it checks for sound support and the OS version(setting it to Win98 or WinME is recommended) and it needs native msvcrt(It even seems to ship it's own version) First chance exception: page fault on write access to 0xffbe95fe in 32-bit code (0x7fe6f359). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:7fe6f359 ESP:7fc0fc54 EBP:7f2603e2 EFLAGS:00210286( - 00 -RISP1) EAX:7fdf4aff EBX:0001 ECX:7fdf0fb0 EDX:7803a11c ESI:7f278aa1 EDI:7f278acc Stack dump: 0x7fc0fc54: 7803a11c 7dbad6d7 7fdf4a38 7f278aa0 0x7fc0fc64: 7f2603e0 0001 7dba1c20 7dbb59b4 0x7fc0fc74: 7f9e24fc 0001 7fa14015 0x7fc0fc84: 7dbb5998 7fa13451 7dbb5998 7f260838 0x7fc0fc94: 0002 7dba9a14 7fa5bda1 0x7fc0fca4: 7fc0fd04 0052ba8b Backtrace: =1 0x7fe6f359 (0x7f2603e2) 2 0x (0x) 0x7fe6f359: addb%dh,0x0(%eax,%eax,1) First chance exception: page fault on read access to 0x3cfbc7b0 in 32-bit code (0x3cfbc7b0). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:3cfbc7b0 ESP:7fc0fc54 EBP:7f2603e1 EFLAGS:00210206( - 00 - RIP1) EAX:607b2c42 EBX:0001 ECX:7fe6e860 EDX:7803a11c ESI:7f278aa0 EDI:7f278acc Stack dump: 0x7fc0fc54: 7fdf47ca 7dbad6d7 7fdf3d08 7f278aa0 0x7fc0fc64: 7f2603e0 0001 7dba1c20 7dbb59b4 0x7fc0fc74: 7f9e24fc 0001 7fa14015 0x7fc0fc84: 7dbb5998 7fa13451 7dbb5998 7f260838 0x7fc0fc94: 0002 7dba9a14 7fa5bda1 0x7fc0fca4: 7fc0fd04 0052ba8b Backtrace: =1 0x3cfbc7b0 (0x7f2603e1) 2 0x (0x) 0x3cfbc7b0: -- no code accessible -- First chance exception: illegal instruction in 32-bit code (0x7fe8f370).
Re: Help with debugging needed
On Thu, 2005-08-11 at 21:39 +, Stefan Dösinger wrote: Hello, I am trying(once again) to get Empire Earth [1] running with wine. After solving a few problems[2], I've run into a strange access violation crash. It looks like a buffer overrun, followed by a return to an invalid adress. A +relay,+snoop trace gives this: ... 0009:CALL Low-Level [EMAIL PROTECTED]@@UAEJXZ() ret=7e2b9a14 0009:CALL Low-Level [EMAIL PROTECTED]@@QAEXXZ() ret=7e2bd6c5 0009:RET Low-Level [EMAIL PROTECTED]@@QAEXXZ() retval=7f24fa70 ret=7e2bd6c5 0009:Call ntdll.RtlEnterCriticalSection(7f074a40) ret=7f0294c5 0009:Ret ntdll.RtlEnterCriticalSection() retval= ret=7f0294c5 0009:Call ntdll.RtlLeaveCriticalSection(7f074a40) ret=7f029506 0009:Ret ntdll.RtlLeaveCriticalSection() retval= ret=7f029506 0009:CALL MSVCRT._except_handler3(unknown, check return) ret=7beb649b 0009:CALL MSVCRT._XcptFilter(unknown, check return) ret=00665947 0009:Call kernel32.GetLastError() ret=7800385f 0009:Ret kernel32.GetLastError() retval=05b4 ret=7800385f 0009:Call kernel32.TlsGetValue() ret=7800386d 0009:Ret kernel32.TlsGetValue() retval=7f180f80 ret=7800386d 0009:Call kernel32.SetLastError(05b4) ret=7800387e 0009:Ret kernel32.SetLastError() retval=05b4 ret=7800387e 0009:Call kernel32.UnhandledExceptionFilter(7fc2f81c) ret=7800ed71 0009:Call ntdll.NtQueryVirtualMemory(,9803a11c,,7fc2f6e8,001c,7fc2f6a8) ret=7fd1aae1 0009:Ret ntdll.NtQueryVirtualMemory() retval= ret=7fd1aae1 0009:Call kernel32.IsBadCodePtr(7800add3) ret=22d2b743 0009:Ret kernel32.IsBadCodePtr() retval= ret=22d2b743 0009:Call ntdll.NtCreateEvent(7fc2f6e8,001f0003,7fc2f6ec,0001,) ret=7fccb9b9 0009:Ret ntdll.NtCreateEvent() retval= ret=7fccb9b9 wine: Unhandled exception (thread 0009), starting debugger... ... The crash messages look a little bit different every time, with illegal instructions / access violations or even a Segmentation Fault without starting winedbg at various addreses(Attached file crashes). On very rare occasions, this crash doesn't occur, and the game continues to load and crashes later in some ddraw function. Instead of crashing it complains about a corrupted heap: err:heap:HEAP_ValidateInUseArena Heap 0x7fd8: prev arena 0x7fe01640 is I've also seen similar problems with related heap functions in WinMM. I'm told that there's something wrong with the heap manager library Wine uses. not prev for in-use 0x7fe01cb0 I've looked at a +heap trace, but I couldn't find anything usefull. (See ee-nocrash for a log). I've also attached a normal log without any special debug flags set(ee-normal.log.gz). I've added a few ERR statements for testing in some functions. So my questions are: *Am I right with my suspection that the problems are caused by a incorrect return? It's possible. I'm working on a problem like that with palm desktop. But you won't know until you debug it :) It could be nasty to fix though. *How can I get a disassembly of Low-Level [EMAIL PROTECTED]@@UAEJXZ or simmilar functions. I didn't find this symbol. If I had to guess, I'd say these functions are in the game itself, most likely in one or more DLLs. Your best bet here is to use a good disassembler. My personal favorite is IDA. You can find a demo version here: http://www.datarescue.be/downloaddemo.htm. This version works just fine for this sort of thing. Thanks for your help, Stefan Dösinger [1] A demo is available at http://www.vugames.de/scripts/download.aspx?content=4id=53721nf=21url=ftp://downloads.vu-games.com/pub/empire%20earth/demos/Empire_earth_EN.exe, but I haven't checked wheter it produces the same results. [2] Other users reported a msvc runtime error, apparently caused by an error returned by Main_DirectDraw_SetCooperativeLevel. EE calls this function with cooplevel == DDSCL_SETFOCUSWINDOW. I made the function simply return DD_OK in this case. Furthermore it checks for sound support and the OS version(setting it to Win98 or WinME is recommended) and it needs native msvcrt(It even seems to ship it's own version) I've had a few programs with this behavior. Programs ship with copies of this library to make sure that it's available, since they can't assume that it'll be there. Normally I stick with native msvcrt in pretty much all cases. I hope this advice helps. Good Hunting ;-) James
