By tracing with softice I found out it passes a fixed memory address to UnmapViewOfFile, as dxantos already said (it first puts 40xxxx in ebx, then pushes ebx), shouldn't you pass the contents of that variable (push dword ptr )?
I tried and the call succeeds and doesn't crash anymore.
It's strange others don't have problems though, do you check if the call succeeds? Maybe it doesn't crash but doesn't succeed either.

Posted on 2002-01-28 13:41:52 by Thomas
Hmm, if UnmapViewOfFile is done on the address of the pointer
variable and not the contents of the pointer variable... you might
actually be unmapping your executable :P. Yay for "hallmarks of a
Microsoft bug in win2k/sp2."
Posted on 2002-01-28 13:45:39 by f0dder
Okay guys, tell me... if you have the return value from MapViewOfFile
in a variable called "mapPtr"... how would you call UnmapViewOfFile?
"invoke UnmapViewOfFile, OFFSET mapPtr" or "invoke UnmapViewOfFile, "
- C equivalents "UnmapViewOfFile(mapPtr);" and "UnmapViewOfFile(&mapPtr);"?
Perhaps *you* can get through to hutch, coz I can't. He still firmly believes
it's a microsoft bug, *grin*.
Posted on 2002-01-28 14:22:47 by f0dder
Interestingly enough, f0dder actually managed to be useful here, the prototype for the UnmapViewOfFile in the compiler I was writing the test with was incorrect and it was using reference instead of the value returned by MapViewOfFile API. I rewrote the prototype and the return value is correct.

It did not happen in the MASM version as it uses DWORD as the prototype. Sad about win2k being the only version to crash the example, perhaps Micro$oft will debug it eventually. :tongue: Those of us who like more or less reliable operating systems still use versions that are far less prone to later Micro$oft bugz.

Posted on 2002-01-28 15:38:29 by hutch--

The 2 test pieces. :)

Posted on 2002-01-28 15:50:53 by hutch--
Works without any problems now, shows '1' in the message box.

Posted on 2002-01-28 16:10:34 by Thomas