Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Help on: GSFAILURE, GSFAILURE_CORRUPTED_EBP, etc.

707 views
Skip to first unread message

j.a. harriman

unread,
Jan 5, 2007, 9:46:01 AM1/5/07
to
I normally don't dump an entire "!analyze -v" output, but I have no clue as
to what could be causing this.
Number of Processors: 2
Processor Type: x86 Family 15 Model 4 Stepping 8
Windows Version: 5.2
Current Build: 3790
Service Pack: 1

This is the first time this has ever occurred. Not only with this program,
but ever.
Any help on how to back track this or discover root issue would be
appreaciated.
Jeff

*******************************************************************************
*
*
* Exception Analysis
*
*
*
*******************************************************************************

couldn't read memory at 0x0040ed10
couldn't read memory at 0x0040ed10

FAULTING_IP:
OurProgramEXE!__rtc_tzz+c0
0040edd0 ?? ???

EXCEPTION_RECORD: ffffffff -- (.exr ffffffffffffffff)
ExceptionAddress: 78141bcd (msvcr80!_output_l+0x000007da)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 8b9f184d
Attempt to read from address 8b9f184d

PROCESS_NAME: OurProgramEXE.exe

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced
memory at "0x%08lx". The memory could not be "%s".

READ_ADDRESS: 8b9f184d

BUGCHECK_STR: STACK_OVERRUN

GSFAILURE_FUNCTION: OurProgramEXE!__rtc_tzz

GSFAILURE_MODULE_COOKIE: <unavailable> OurProgramEXE!__security_cookie [
00412b10 ]

GSFAILURE_CORRUPTED_EBP: Found 00344a40 on stack instead of 0012f2dc

GSFAILURE_ANALYSIS_TEXT: !gs output:
Stack buffer overrun analysis follows:

Corruption occured in OurProgramEXE!__rtc_tzz or one of its callers
Error reading real canary at 0x00412b10
Error reading real canary complement at 0x00000000
GS analysis will be limited due to previous errors
Corrupted cookie value (0x00000000) too generic, skipping read bit-flip check
A caller of OurProgramEXE!__rtc_tzz has corrupted the EBP from 0x0012f2dc to
0x00344a40
Check callers (without canary) of OurProgramEXE!__rtc_tzz for 3 bytes of
overflow
The canary doesn't look corrupted. Not sure how we got here
Error 0 checking LEA EBP/ESP usage
EBP/ESP check skipped: Error checking 'LEA EBP/ESP' usage
Function OurProgramEXE!__rtc_tzz:
Funtion has no locals
no candidate buffer found

Stack buffer overrun analysis complete.


DEFAULT_BUCKET_ID: GS_FALSE_POSITIVE_STACK_POINTER_CORRUPT

LAST_CONTROL_TRANSFER: from 7817819f to 78141bcd

STACK_TEXT:
0012ef38 7817819f 0012ef54 00409900 00000000 msvcr80!_output_l+0x7da
[f:\rtm\vctools\crt_bld\self_x86\crt\src\output.c @ 1646]
0012ef74 781781b9 781413f3 00409900 00000000 msvcr80!_vscprintf_helper+0x4f
[f:\rtm\vctools\crt_bld\self_x86\crt\src\vsprintf.c @ 405]
0012ef88 781f49f9 00409900 0012efbc 0012f054 msvcr80!_vscprintf+0x14
[f:\rtm\vctools\crt_bld\self_x86\crt\src\vsprintf.c @ 414]
0012efa0 781f6793 00409900 0012efbc 00401a3f
mfc80!ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> >
>::FormatV+0x23 [f:\rtm\vctools\vc7libs\ship\atlmfc\include\cstringt.h @ 2142]
0012efa4 00409900 0012efbc 00401a3f 0012efe0
mfc80!ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> >
>::Format+0x12 [f:\rtm\vctools\vc7libs\ship\atlmfc\include\cstringt.h @ 2539]
0012f2d8 0040edd0 0012fafc 0012fb1c 782975cd
OurProgramEXE!__report_gsfailure+0xe2
[f:\rtm\vctools\crt_bld\self_x86\crt\src\gs_report.c @ 313]
0012f2dc 0012fafc 0012fb1c 782975cd 34317872 OurProgramEXE!__rtc_tzz+0xc0
WARNING: Frame IP not in any known module. Following frames may be wrong.
0012f2e0 0012fb1c 782975cd 34317872 0074736d 0x12fafc
0012fafc 00000000 00000000 00000000 00000000 0x12fb1c


STACK_COMMAND: ~0s; .ecxr ; kb

FAULTING_THREAD: 0000384c

FOLLOWUP_IP:
OurProgramEXE!__rtc_tzz+c0
0040edd0 ?? ???

SYMBOL_STACK_INDEX: 6

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: OurProgramEXE

IMAGE_NAME: OurProgramEXE.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 45886395

SYMBOL_NAME: OurProgramEXE!__rtc_tzz+c0

FAILURE_BUCKET_ID: STACK_OVERRUN_OurProgramEXE!__rtc_tzz+c0

BUCKET_ID: STACK_OVERRUN_OurProgramEXE!__rtc_tzz+c0

Followup: MachineOwner
---------


Ivan Brugiolo [MSFT]

unread,
Jan 5, 2007, 1:35:58 PM1/5/07
to

Immagine you have code like

VOID function(char * SomeString) {
char Buffer[4];
sprintf(Buffer,"%s",SomeString);
}

compiled with /GS, and,

int __cdecl main(int argc, wchar *argv[]) {
function("long string");
}

Being this a chassical buffer overrun, you can expect that
the return address of the `function` function has been overwritten.

The best you can get out of this is to analyze the output of
`dds poi(@$teb+8) poi(@$teb+4)`
looking for a probable call stack
--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"j.a. harriman" <jeffrey_no...@nospam.nospam> wrote in message
news:D574E606-8DCC-46F1...@microsoft.com...

j.a. harriman

unread,
Jan 8, 2007, 11:12:00 AM1/8/07
to
Ivan,

I am getting the following:
0:000> dds poi(@$teb+8) poi(@$teb+4)
Memory access error at ') poi(@$teb+4)'

Is that due to the corruption?

How did you know to look at the TEB register?

Thanks.

0 new messages