I've been stumped for a while on this problem now and have thoroughly tested this issue so I'll reward 350 minerals to whoever can solve this.

I'm writing a DLL called CheckRevision(the file is named IX86Ver1.dll which is embedded in a signed MPQ file; that MPQ file is sent to the clients) which is downloaded and loaded by Battle.net clients when connecting to a server. The data returned by CheckRevision is information about the client(exe) which is detailed in the documentation of packet 0x51. This data includes the last modified time of the client; the call to Filesystem's last_write_time() function is where a fatal error is thrown on Windows XP(SP 3), but (the SAME binary file) executes successfully in Windows Vista, Windows 7, Windows 8, and Windows 10.

The DLL is compiled using Visual Studio 2015 with the Platform Toolset option set to Visual Studio 2015 - Windows XP (v140_xp).

Disturbingly, the DLL file does not seem to be the problem at all. I've wrote a simple exe program that loads the DLL and calls the CheckRevision function from it successfully. In conclusion, it seems that there is probably faulty code in the calling program, WarCraft 3, but why is it only faulty for Windows XP but not any other versions of Windows? But wait, how is there faulty code in WarCraft 3 when a fatal error is thrown at the call to last_write_time() which is located in CheckRevision?

Screenshot of the error message: http://i.imgur.com/5pqPpN3.png
Source of DLL: https://bpaste.net/show/25e6b36b0351
Source of test program: https://bpaste.net/show/1d9a10ba54ec

Attachments:

Post has been edited 4 time(s), last time on Sep 17 2015, 6:07 pm by iCCup.xboi209.

You could compile dll using mingw and see how they work. (Even though it really doesn't tell too much)

If you can install stuff on the XP machine you use, try using Application Verifier, as it can detect heap buffer overflows and other misc issues in Warcraft 3 exe. Dr. Memory is another similar tool, though I don't know if it works at all here. Also at least AMD video drivers are so buggy that Application Verifier may give complaints unrelated to issue, but they can just be ignored.

Otherwise have fun debugging

I'm using TR2's filesystem which mingw doesn't have and I suck at compiling Boost Filesystem

Oh..

Anyways, last_write_time is really simple function, so the crash should be easy to solve with a debugger. Not sure if you can use vs 2015 debugger on xp, but any debugger should give some information on the crash. Especially as the crash locations seems not to be in system dlls?