I have a complicated 32-bit multi-threaded program running on a 64-bit Windows Server 2008 R2 Enterprise SP1 system.
Running under the MSVC debugger, I sometimes stop with an access violation reported on an instruction inside winsock code, an instruction that has no obvious reason to be causing an exception. A typical example:
82 threads reported by the debugger. The one that is selected when the access violation triggers a program break shows this...
Registers:
EAX = 0DBC9918 EBX = 54007022
ECX = 00374248 EDX = 00000000
ESI = 00000000 EDI = 00370924
EIP = 745616B4 ESP = 0DBC98C8
EBP = 0DBC9934 EFL = 00010246
Disassembly:
745616B4 68 27 2F 58 74 push 74582F27h
745616B9 64 FF 35 00 00 00 00 push dword ptr fs:[0]
745616C0 8B 44 24 10 mov eax,dword ptr [esp+10h]
745616C4 89 6C 24 10 mov dword ptr [esp+10h],ebp
Memory (address esp-4)
0DBC98C4 00370844 745636C2 74563808 0000003C
0DBC98D4 75B83D70 00000002 00000001 00000000
The stack frontier data comes from a couple of pushes and a call that seem to have worked just fine:
745636B6 6A 3C push 3Ch
745636B8 68 08 38 56 74 push 74563808h
745636BD E8 F2 DF FF FF call 745616B4
745636C2 ...
It doesn't seem like the push at should be hitting a guard page exception, given its address and the successful pushes that preceded it. The other threads don't seem to be likely candidates for causing the exception, judging from the call-stack info. I don't know whether there's some mechanism I'm overlooking that could generate that access violation on that instruction, or whether the debugger is misleading me. Any light you can shed would be appreciated.
