I only suggest this as a possibility, and then only if you are using a client OS (the OS you run game.exe under, I don't care what the server runs on) newer than XP (or 2003).
The usual outcome is that the write operation gets virtualised off by the virtual folders system... but if (for what ever reason) that is not possible, the operation will fail, and instead of being returned a file handle for the new file, game.exe will receive a null, and a new LastError() code.
An attempt to pass data to a null file handle is an "illegal operation" and will usually result in the kernel passing faults to the SEH (Structured Exception Handler) which does very little in PT, unless the error is DirectDraw related (in which case it writes an error log) asset related (in which case it writes a line to AssaError.log) or from WS32 (WinSock) in which case you will get the dreaded "DC" message before the game quits.
If the SEH doesn't process the error, it then falls to the kernel to deal with it. The usual way of doing that is to close the offending application to prevent further corruption to other applications on the system.
How the close down happens depends greatly on your OS configuration. It often leads to a "DrWatson" debug and memory dump. It should also make a new entry in the System Application Log.
If you have the Error Reporting Service running, you may receive a notification, and if you are configured to participate in the Windows Improvement Program, you may be offered to send the details of the crash to Microsoft for analysis. If you have a development environment with a built in debugger, such as TDbg (Borland), gdbg (GNU) or Microsoft Debugger installed, they may take precedence over DrWatson.
Independent debuggers, such as SoftICE or OllyDbg can also be configured as the system wide crash debugger. Likewise, it is possible to implement an independent SEH layer between your application and the kernel, and possible to bypass DrWatson and the Error Reporting Service and the Event Log so that less actually happens than if you "End Task" force quit game.exe from the task manager.
Different versions of Windows, Service Packs (especially for XP) and application installations will affect
exactly what happens and how much information you receive under different types of crash greatly. So just saying the game quits out, doesn't really tell us much.
If you are running the game with OllyDbg attached, you could maybe trace the stack back from the exit point. If the exit point is within the main module, then the exit is programmed into the game it's self, and is either done because it's SEH
did intercept and handle (all be it badly) the error, or because someone has written out the screen print code in that client. If it comes from kernel32.dll then the error has fallen through to the kernel and it has forced the application to quit, but if you follow the return addresses in the stack, they should still lead back to code in the main module near the instruction that caused the kernel to terminate the process, which will give you an idea why it went wrong.
You can set a breakpoint on that instruction, and maybe one on what you suspect to be the entry point of that routine, and see if you can see what it is doing that it shouldn't, or what it isn't doing that it should.
All of which takes someone with a reasonably good understanding of the code being analysed and the OS on which it is being run sat at the machine tracing what it is actually doing when the problem presents.
This is not a problem you want to fight with if you are new to configuring and moding PT. You want to be comfortable with it at a low level when it is working properly before you try to tackle this.
The easy stuff?... Does it happen this way on other machines with different OS versions? Does it still happen if you run game.exe from a copy of the folder it is installed to residing on
your user desktop?
If the fist is true, it's a bug in game.exe. If the second is false then it's a conflict with current OS application security, and without a
lot of work, this client will never be happy on current OS (Vista, 2008 & Se7en). Funny thing is, that isn't usually what people notice first. XD
If the game.exe is just falling over anyway... there are some "delicate" things that happen when a screen capture is taken. A new DIB is created the same size as the display. DIBs are bigger than the DCs used in the "frame buffer" (if you can call it that in PT). An exact copy of the DC being rendered (this is a bug, as it should be the last frame displayed) is then copied from the DC to the newly created DIB. This is then converted to a BMP, or JPG depending on which screen capture hotkey combination you pressed. The JPG is very heavily compressed, and to compensate for that, they up-sample the image rather than decreasing the compression. Don't ask me why. All of which is fairly intensive on memory, in a game that is already way too memory intensive for what it does... So you could try looking for memory outages either in main memory (which should spill over into the swap file unless that is exhausted too) or graphics memory. The client refers to this as VRAM if you are logged in as a GM.
Running out of available memory would present the exact same way. An illegal operation passed to the SEH, and if that doesn't deal with it on to the kernel to kill the process. However, I'm sure there are many other errors that would also present this way, and I wouldn't be surprised to find other people here have some ideas on that. I
suspect these are the most likely, but I don't know your setup. I also
suspect that what I have suggested is boggling your mind already, so going through the many possibilities is unnecessary. I cannot think of an easier way to hunt down this error... maybe someone else has seen it before and can bypass some of the techno-bable. XD
Good luck.
