GetSystemTime causes exception?

  • Thread starter Thread starter Alan Williams-Key
  • Start date Start date
A

Alan Williams-Key

I have a very strange exception caused by my program reported by a user. The
report states:
___________________________________________________________________
application caused an Access Violation (0xc0000005)
in module application.exe at 001b:6036e161.
....
Read from location 00000d02 caused an access violation.

Context:
EDI: 0x6045db70 ESI: 0x60429be0 EAX: 0x0012f6c4
EBX: 0x00000001 ECX: 0x00000231 EDX: 0x00000034
EIP: 0x6036e161 EBP: 0x00000d12 SegCs: 0x0000001b
EFlags: 0x00010246 ESP: 0x0012f6c0 SegSs: 0x00000023
___________________________________________________________________

Note the suspect value of EBP. The source code for this address is:

__int64 systemTime()
{
SYSTEMTIME st;
__int64 res;
GetSystemTime(&st);
res = st.wHour;
…

and the assembler, taken straight from the VS debugger, is:
__________________________________________________________________

205: __int64 systemTime()
206: {
6036E150 push ebp
6036E151 mov ebp,esp
6036E153 sub esp,18h
6036E156 push esi
207: SYSTEMTIME st;
208: __int64 res;
209: GetSystemTime(&st);
6036E157 lea eax,[st]
6036E15A push eax
6036E15B call dword ptr [__imp__GetSystemTime@4 (604290e8)]
210: res = st.wHour;
6036E161 mov eax,dword ptr [ebp-10h]
_____________________________________________________________

The only explanation I can see is that GetSystemTime() is causing the
problem by corrupting EBP before it returns. Can anyone see any other
explanation? Has anyone else come across a problem with this function? (The
user is running on XP SP2 on a Mac, in case this is significant.)
 
Alan said:
I have a very strange exception caused by my program reported by a
user. The report states:
___________________________________________________________________
application caused an Access Violation (0xc0000005)
in module application.exe at 001b:6036e161.
...
Read from location 00000d02 caused an access violation.

Context:
EDI: 0x6045db70 ESI: 0x60429be0 EAX: 0x0012f6c4
EBX: 0x00000001 ECX: 0x00000231 EDX: 0x00000034
EIP: 0x6036e161 EBP: 0x00000d12 SegCs: 0x0000001b
EFlags: 0x00010246 ESP: 0x0012f6c0 SegSs: 0x00000023
___________________________________________________________________

Note the suspect value of EBP. The source code for this address is:

__int64 systemTime()
{
SYSTEMTIME st;
__int64 res;
GetSystemTime(&st);
res = st.wHour;
…

and the assembler, taken straight from the VS debugger, is:
__________________________________________________________________

205: __int64 systemTime()
206: {
6036E150 push ebp
6036E151 mov ebp,esp
6036E153 sub esp,18h
6036E156 push esi
207: SYSTEMTIME st;
208: __int64 res;
209: GetSystemTime(&st);
6036E157 lea eax,[st]
6036E15A push eax
6036E15B call dword ptr [__imp__GetSystemTime@4 (604290e8)]
210: res = st.wHour;
6036E161 mov eax,dword ptr [ebp-10h]
_____________________________________________________________

The only explanation I can see is that GetSystemTime() is causing the
problem by corrupting EBP before it returns. Can anyone see any other
explanation? Has anyone else come across a problem with this
function? (The user is running on XP SP2 on a Mac, in case this is
significant.)
Click to expand...

Is the problem reproducable? You surely know that the WINAPI calling
convention (like others) ensures that the EBP register is saved and restored
before the function returns. For this reason, and as I don't see a flaw in
your code, I strongly believe that it is a hardware issue, so I'd run
Memtest86+ on that machine. Maybe Prime95 afterwards. GetSystemTime() is
such a frequently called function that you probably wouldn't be able to boot
the system if there was a wrong image on the disk.


Armin
 
Armin said:
Alan said:
I have a very strange exception caused by my program reported by a
user. The report states:
___________________________________________________________________
application caused an Access Violation (0xc0000005)
in module application.exe at 001b:6036e161.
...
Read from location 00000d02 caused an access violation.

Context:
EDI: 0x6045db70 ESI: 0x60429be0 EAX: 0x0012f6c4
EBX: 0x00000001 ECX: 0x00000231 EDX: 0x00000034
EIP: 0x6036e161 EBP: 0x00000d12 SegCs: 0x0000001b
EFlags: 0x00010246 ESP: 0x0012f6c0 SegSs: 0x00000023
___________________________________________________________________

Note the suspect value of EBP. The source code for this address is:

__int64 systemTime()
{
SYSTEMTIME st;
__int64 res;
GetSystemTime(&st);
res = st.wHour;
.

and the assembler, taken straight from the VS debugger, is:
__________________________________________________________________

205: __int64 systemTime()
206: {
6036E150 push ebp
6036E151 mov ebp,esp
6036E153 sub esp,18h
6036E156 push esi
207: SYSTEMTIME st;
208: __int64 res;
209: GetSystemTime(&st);
6036E157 lea eax,[st]
6036E15A push eax
6036E15B call dword ptr [__imp__GetSystemTime@4 (604290e8)]
210: res = st.wHour;
6036E161 mov eax,dword ptr [ebp-10h]
_____________________________________________________________

The only explanation I can see is that GetSystemTime() is causing the
problem by corrupting EBP before it returns. Can anyone see any other
explanation? Has anyone else come across a problem with this
function? (The user is running on XP SP2 on a Mac, in case this is
significant.)
Click to expand...

Is the problem reproducable? You surely know that the WINAPI calling
convention (like others) ensures that the EBP register is saved and
restored before the function returns. For this reason, and as I don't
see a flaw in your code, I strongly believe that it is a hardware
issue, so I'd run Memtest86+ on that machine. Maybe Prime95
afterwards. GetSystemTime() is such a frequently called function that
you probably wouldn't be able to boot the system if there was a wrong
image on the disk.
Click to expand...

Adding some ideas: OP, check loaded Dlls, some application could be injecting
code (to "detour" (instrument) functions) in your program. To check this (beside
looking for Dlls) compare the "release" static assembler code with the client
running assembler code. Some instrumenting libraries (like Microsoft Detours)
dinamically modify code to intercept functions (BTW, MS Detours has known bugs
that can lead to application crash).

Armin
Click to expand...

Regards
 
Back
Top