strncmp bugcheck 0x7e (c0000005 - access violation)

NTDEV
1

im having bugcheck 0xce DRIVER_UNLOADED_WITHOUT_CANCELLING_PENDING_OPERATIONS with my driver. so i enable driver verifier & restart

so i got this bugcheck : 1000007E, {c0000005, 9917e9ef, 860b7a10, 860b75f0}

this is my crashdump analysis
2: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 9917e9ef, The address that the exception occurred at
Arg3: 860b7a10, Exception Record Address
Arg4: 860b75f0, Context Record Address

Debugging Details:

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

FAULTING_IP:
GWDogProc!getOffset+9f [k:\driver35\gwdogproc_3.5\main.c @ 441]
9917e9ef 8b1491 mov edx,dword ptr [ecx+edx*4]

EXCEPTION_RECORD: 860b7a10 -- (.exr 0xffffffff860b7a10)
ExceptionAddress: 9917e9ef (GWDogProc!getOffset+0x0000009f)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 3415cffc
Attempt to read from address 3415cffc

CONTEXT: 860b75f0 -- (.cxr 0xffffffff860b75f0)
eax=81f809c0 ebx=00000000 ecx=81e87800 edx=ec8b55ff esi=983ed468 edi=983dd000
eip=9917e9ef esp=860b7ad8 ebp=860b7ad8 iopl=0 nv up ei ng nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010286
GWDogProc!getOffset+0x9f:
9917e9ef 8b1491 mov edx,dword ptr [ecx+edx*4] ds:0023:3415cffc=????????
Resetting default scope

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VERIFIER_ENABLED_VISTA_MINIDUMP

PROCESS_NAME: System

CURRENT_IRQL: 0

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

EXCEPTION_PARAMETER1: 00000000

EXCEPTION_PARAMETER2: 3415cffc

READ_ADDRESS: Unable to read MiSystemVaType memory at 81f60160
3415cffc

FOLLOWUP_IP:
GWDogProc!getOffset+9f [k:\driver35\gwdogproc_3.5\main.c @ 441]
9917e9ef 8b1491 mov edx,dword ptr [ecx+edx*4]

BUGCHECK_STR: 0x7E

LAST_CONTROL_TRANSFER: from 81fbb73e to 9917e9ef

STACK_TEXT:
860b7ad8 81fbb73e 983ed468 983dd000 00000000 GWDogProc!getOffset+0x9f [k:\driver35\gwdogproc_3.5\main.c @ 441]
860b7cbc 81fb94af 00000001 00000000 860b7ce4 nt!IopLoadDriver+0x7ed
860b7d00 81e8603b 8649dcd0 00000000 8438e4c0 nt!IopLoadUnloadDriver+0x70
860b7d50 820269df 00000001 a216202f 00000000 nt!ExpWorkerThread+0x10d
860b7d90 81ed81d9 81e85f2e 00000001 00000000 nt!PspSystemThreadStartup+0x9e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19

FAULTING_SOURCE_CODE:
437: // DbgPrint("running win Server03");
438:
439: strncpy(CallerProcessName,(PCHAR)PsInitialSystemProcess + 356,NT_PROCNAMELEN );
440: // DbgPrint("Process: %s",CallerProcessName);

441: if (strncmp(CallerProcessName,"System",6)==0)
442: {
443: // DbgPrint("It is System - R2");
444: return 356; //Server R2
445: }
446:

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: GWDogProc!getOffset+9f

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: GWDogProc

IMAGE_NAME: GWDogProc.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4d81af9d

STACK_COMMAND: .cxr 0xffffffff860b75f0 ; kb

FAILURE_BUCKET_ID: 0x7E_VRF_GWDogProc!getOffset+9f

BUCKET_ID: 0x7E_VRF_GWDogProc!getOffset+9f

im not very good at debugging.
i dont understand. Why do i get access violation when i strncmp(CallerProcessName,"System",6). can somebody give me a hint

thanks

2

First of all, it fails on ‘strncpy’, not on ‘strncmp’. Could you show how ‘CallerProcessName’ and ‘NT_PROCNAMELEN’ are defined?

P.S. I assume that you understand that manipulating EPROCESS directly is very unstable and not future-version-compatible way.

3

Well my guess would be that since you are using a call that relies on a
NULL terminated string on a string that is essentially almost never NULL
terminated that you are running off the end.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“xxxxx@yahoo.com” wrote in message
news:xxxxx@ntdev:

> First of all, it fails on ‘strncpy’, not on ‘strncmp’. Could you show how ‘CallerProcessName’ and ‘NT_PROCNAMELEN’ are defined?
>
> P.S. I assume that you understand that manipulating EPROCESS directly is very unstable and not future-version-compatible way.

4

sorry. could you tell how you determine that strncpy is the function where
it fails.
i thought strncmp is the one which failed because of this

FAULTING_IP:

GWDogProc!getOffset+9f [k:\driver35\gwdogproc_3.5\
main.c* @ 441*]
9917e9ef 8b1491 mov edx,dword ptr [ecx+edx*4]

the *@441*. so when i refer to the code line it is

441: if (strncmp(CallerProcessName,“System”,6)==0)

i define NT_PROCNAMELEN & CallerProcessName as

#define NT_PROCNAMELEN 16

CHAR CallerProcessName[NT_PROCNAMELEN];

On Wed, Mar 23, 2011 at 8:34 PM, wrote:

> First of all, it fails on ‘strncpy’, not on ‘strncmp’. Could you show how
> ‘CallerProcessName’ and ‘NT_PROCNAMELEN’ are defined?
>
> P.S. I assume that you understand that manipulating EPROCESS directly is
> very unstable and not future-version-compatible way.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

5

Strange,

GWDogProc!getOffset+0x9f:
9917e9ef 8b1491 mov edx,dword ptr [ecx+edx*4]

ecx=81e87800 edx=ec8b55ff

while ecx looks like correct base address (probably points to EPROCESS of System) edx is totally wrong. I think you could publish source code of getOffset function and its compiled source (disassembly). It will give more information, so someone (e.g. me) will understand why edx looks overflowed…

6

xxxxx@gmail.com wrote:

im having bugcheck 0xce DRIVER_UNLOADED_WITHOUT_CANCELLING_PENDING_OPERATIONS with my driver. so i enable driver verifier & restart

so i got this bugcheck : 1000007E, {c0000005, 9917e9ef, 860b7a10, 860b75f0}
…
Debugging Details:

…
CONTEXT: 860b75f0 – (.cxr 0xffffffff860b75f0)
eax=81f809c0 ebx=00000000 ecx=81e87800 edx=ec8b55ff esi=983ed468 edi=983dd000
eip=9917e9ef esp=860b7ad8 ebp=860b7ad8 iopl=0 nv up ei ng nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010286
GWDogProc!getOffset+0x9f:
9917e9ef 8b1491 mov edx,dword ptr [ecx+edx*4] ds:0023:3415cffc=???
…
FAULTING_SOURCE_CODE:
437: // DbgPrint(“running win Server03”);
438:
439: strncpy(CallerProcessName,(PCHAR)PsInitialSystemProcess + 356,NT_PROCNAMELEN );
440: // DbgPrint(“Process: %s”,CallerProcessName);
> 441: if (strncmp(CallerProcessName,“System”,6)==0)
442: {
443: // DbgPrint(“It is System - R2”);
444: return 356; //Server R2
445: }
446:
…
im not very good at debugging.
i dont understand. Why do i get access violation when i strncmp(CallerProcessName,“System”,6). can somebody give me a hint

Yes. The debugger is not all-powerful. It makes its best GUESS at
figuring out which line of code caused the failure, but it does not
always guess correctly, especially in a free build where optimizations
are enabled.

It cannot be the strncmp, because strncmp doesn’t generate code like
that. In fact, it’s not clear that anything in that sequence of code
would generate code like that. I don’t see anything that would be
indexed 4 bytes at a time. indeed, there’s no indexing at all here…
Is it possible your driver binary is from an earlier version of the
source? Remember, even when the debugger thinks the problem was at line
441, if the source code has changed, line 441 doesn’t point to the same
line it used to.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

7

suki minna wrote:

i define NT_PROCNAMELEN & CallerProcessName as

#define NT_PROCNAMELEN 16

CHAR CallerProcessName[NT_PROCNAMELEN];

Is that a global? A local to the function?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

8

NT_PROCNAMELEN is global

CallerProcessName is local in that function

On Thu, Mar 24, 2011 at 12:19 AM, Tim Roberts wrote:

> suki minna wrote:
> >
> > i define NT_PROCNAMELEN & CallerProcessName as
> >
> > #define NT_PROCNAMELEN 16
> >
> >
> > CHAR CallerProcessName[NT_PROCNAMELEN];
> >
> >
>
> Is that a global? A local to the function?
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

9

suki minna wrote:

NT_PROCNAMELEN is global

CallerProcessName is local in that function

As I said, the code you posted would not generate the instruction that
faulted. If you show us the entire source for the getOffset function,
perhaps we can spot the problem.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

10

OK…here is the code. its nothing more than comparing version of OS and
returning certain constant

int getOffset()
{
ULONG majorVersion;
ULONG minorVersion;

PsGetVersion(&majorVersion, &minorVersion, NULL, NULL);
if(majorVersion == 5 && minorVersion == 0)
{
// win2k
// DbgPrint(“running win2k”);
return 508;
}
if(majorVersion == 5 && minorVersion == 1)
{
// winXP
// DbgPrint(“running winXP”);
return 372;
}
if(majorVersion == 6 && minorVersion == 0)
{
// winVista
#if defined(AMD64)
// DbgPrint(“vista AMD64”);
return 568;
#endif
// winVista
// DbgPrint(“running winVista”);
return 332;
}
if(majorVersion == 6 && minorVersion == 1)
{
#if defined(AMD64)
// DbgPrint(“running win 7 AMD64”);
return 736;
#endif

// win7
// DbgPrint(“running win7”);
return 364;

}
if(majorVersion == 5 && minorVersion == 2)
{
// winSrv2003 R2
#if defined(AMD64)
// DbgPrint(“running win 7 AMD64”);
return 616;
#endif

// need to actually check the offset
CHAR CallerProcessName[NT_PROCNAMELEN];

// DbgPrint(“running win Server03”);

strncpy(CallerProcessName,(PCHAR)PsInitialSystemProcess +
356,NT_PROCNAMELEN );
DbgPrint(“Process: %s”,CallerProcessName);
if (strncmp(CallerProcessName,“System”,6)==0)
{
// DbgPrint(“It is System - R2”);
return 356; //Server R2
}

// DbgPrint(“Assuming - R1”);
return 340; //Server R1

}

return 0;
}

On Thu, Mar 24, 2011 at 12:30 AM, Tim Roberts wrote:

> suki minna wrote:
> > NT_PROCNAMELEN is global
> >
> > CallerProcessName is local in that function
>
> As I said, the code you posted would not generate the instruction that
> faulted. If you show us the entire source for the getOffset function,
> perhaps we can spot the problem.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

11

The code looks good except for one thing:

DbgPrint(“Process: %s”,CallerProcessName);

‘CallerProcessName’ is not NULL-terminated, while %s modifier expects NULL-terminated string. On the other side I saw it commented in your first post… Anyway you shouldn’t expect that CallerProcessName is NULL-terminated or you can add NULL by yourself.

12

What are you trying to accomplish that is causing you to grovel into the EPROCESS structure like this? This approach is neither supportable nor sustainable. Shipping code should not be doing this sort of thing.

  • S

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of suki minna
Sent: Wednesday, March 23, 2011 9:38 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] strncmp bugcheck 0x7e (c0000005 - access violation)

OK…here is the code. its nothing more than comparing version of OS and returning certain constant

int getOffset()
{
ULONG majorVersion;
ULONG minorVersion;

PsGetVersion(&majorVersion, &minorVersion, NULL, NULL);
if(majorVersion == 5 && minorVersion == 0)
{
// win2k
// DbgPrint(“running win2k”);
return 508;
}
if(majorVersion == 5 && minorVersion == 1)
{
// winXP
// DbgPrint(“running winXP”);
return 372;
}
if(majorVersion == 6 && minorVersion == 0)
{
// winVista
#if defined(AMD64)
// DbgPrint(“vista AMD64”);
return 568;
#endif
// winVista
// DbgPrint(“running winVista”);
return 332;
}
if(majorVersion == 6 && minorVersion == 1)
{
#if defined(AMD64)
// DbgPrint(“running win 7 AMD64”);
return 736;
#endif

// win7
// DbgPrint(“running win7”);
return 364;

}
if(majorVersion == 5 && minorVersion == 2)
{
// winSrv2003 R2
#if defined(AMD64)
// DbgPrint(“running win 7 AMD64”);
return 616;
#endif

// need to actually check the offset
CHAR CallerProcessName[NT_PROCNAMELEN];

// DbgPrint(“running win Server03”);

strncpy(CallerProcessName,(PCHAR)PsInitialSystemProcess + 356,NT_PROCNAMELEN );
DbgPrint(“Process: %s”,CallerProcessName);
if (strncmp(CallerProcessName,“System”,6)==0)
{
// DbgPrint(“It is System - R2”);
return 356; //Server R2
}

// DbgPrint(“Assuming - R1”);
return 340; //Server R1

}

return 0;
}
On Thu, Mar 24, 2011 at 12:30 AM, Tim Roberts > wrote:
suki minna wrote:
> NT_PROCNAMELEN is global
>
> CallerProcessName is local in that function
As I said, the code you posted would not generate the instruction that
faulted. If you show us the entire source for the getOffset function,
perhaps we can spot the problem.

–
Tim Roberts, xxxxx@probo.commailto:xxxxx
Providenza & Boekelheide, Inc.

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx>