BSOD occurs when copy datas in Windows7 System Thread

Hi, I’m developing I/F Card Driver in WindowsXP 32bit & Windows7 Ultimate x64

I could successfully copy all datas in WindowsXP 32bit.

But When I execute copy in Windows7_Ultimate_x64 always BSOD occurs.
I’m using Intel Xeon(R) W3503 @ 2.4G for my CPU.

It seems that address space problem but I don’t know exactly.

Please look at my code below.

  1. it is SystemThread Routine
    void ThreadProc(PDEVICE_EXTENSION pdx) {

NTSTATUS status;
UINT32 nCmd;
UINT32 addrFrom, addrTo, transLength;

while (1) {
status = KeWaitForSingleObject(&pdx->eventThread, Executive, KernelMode, FALSE, 0);

nCmd = pdx->cmdThread;

switch (nCmd) {
case CMD_THREAD_STOP :
PsTerminateSystemThread(STATUS_SUCCESS);
break;
case CMD_THREAD_MEMCPY:
addrFrom = (UINT32) pdx->pvVirtualTransBuffer[pdx->nCurDataIndex%4];
addrTo = (UINT32) pdx->sysVA + 2*1024*1024 * pdx->nCurDataIndex;
transLength = (pdx->InterruptTransLength >= 2*1024*1024) ? 2*1024*1024 : pdx->InterruptTransLength;

KdPrint((DRIVERNAME “Memcpy Idx : %d From : %08x, To : %08x, Length : %08x”, pdx->nCurDataIndex, addrFrom, addrTo, transLength));
if ((addrTo != 0)&&(addrFrom != 0)) {
memcpy((void *) addrTo, (void *) addrFrom, transLength);
}
break;
}
}
}

And It’s Bug Analysis Result

0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
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.
Arguments:
Arg1: ffffffffc0000005, The exception code that was not handled
Arg2: fffff8800aecaddb, The address that the exception occurred at
Arg3: fffff88005c7da98, Exception Record Address
Arg4: fffff88005c7d300, Context Record Address

Debugging Details:

ADDITIONAL_DEBUG_TEXT:
Use ‘!findthebuild’ command to search for the target build information.
If the build information is available, run ‘!findthebuild -s ; .reload’ to set symbol path and load symbols.

FAULTING_MODULE: fffff8000304d000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 4e1fe159

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - 0x%08lx

FAULTING_IP:
isdpcixp!ThreadProc+15b [d:\cks\codes\pci_express\pcixp_srio\pcv_driver\plugplay.c @ 706]
fffff880`0aecaddb f3a4 rep movs byte ptr [rdi],byte ptr [rsi]

EXCEPTION_RECORD: fffff88005c7da98 – (.exr 0xfffff88005c7da98)
ExceptionAddress: fffff8800aecaddb (isdpcixp!ThreadProc+0x000000000000015b)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: 000000000cc01000
Attempt to read from address 000000000cc01000

CONTEXT: fffff88005c7d300 – (.cxr 0xfffff88005c7d300)
rax=0000000000000001 rbx=fffffa8007e3ab60 rcx=0000000000200000
rdx=000000000000004b rsi=000000000cc01000 rdi=0000000011800000
rip=fffff8800aecaddb rsp=fffff88005c7dcd0 rbp=0000000000000080
r8=0000000000000065 r9=0000000000000003 r10=6449207970636d65
r11=000000000000000c r12=fffffa8007ee1790 r13=fffff8800aecac80
r14=0000000000000000 r15=fffff80000b96080
iopl=0 nv up ei pl nz na po nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010206
isdpcixp!ThreadProc+0x15b:
fffff880`0aecaddb f3a4 rep movs byte ptr [rdi],byte ptr [rsi]
Resetting default scope

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x7E

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff80003360bc6 to fffff8800aecaddb

STACK_TEXT:
fffff88005c7dcd0 fffff80003360bc6 : fffffa8007ee1790 fffff80003360b6c 0000000000000010 0000000000010286 : isdpcixp!ThreadProc+0x15b [d:\cks\codes\pci_express\pcixp_srio\pcv_driver\plugplay.c @ 706]
fffff88005c7dd40 fffff8000309bbc6 : fffff80003237e80 fffffa8007e3ab60 fffffa8005e89040 fffff88001423534 : nt!PsCreateSystemThread+0x6e2
fffff88005c7dd80 0000000000000000 : fffff88005c7e000 fffff88005c78000 fffff88005c7d9a0 0000000000000000 : nt!KeTestAlertThread+0x946

FOLLOWUP_IP:
isdpcixp!ThreadProc+15b [d:\cks\codes\pci_express\pcixp_srio\pcv_driver\plugplay.c @ 706]
fffff880`0aecaddb f3a4 rep movs byte ptr [rdi],byte ptr [rsi]

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: isdpcixp!ThreadProc+15b

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: isdpcixp

IMAGE_NAME: isdpcixp.sys

STACK_COMMAND: .cxr 0xfffff88005c7d300 ; kb

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner

706th line is memcpy
memcpy((void *) addrTo, (void *) addrFrom, transLength);

Please Help me to find what could cause this problem

> UINT32 addrFrom, addrTo, transLength;

You are using 32 bit UINT to hold a 64 bit address??? That’s never going
to work.

James

Thank you very much Mr. James

I could finish this terrible jobs because of your smart words!

I could finish this job with #ifdef _WIN64

Thank you very much again.
Have a nice day. bye~

2011/7/15 James Harper

> > UINT32 addrFrom, addrTo, transLength;
>
> You are using 32 bit UINT to hold a 64 bit address??? That’s never going
> to work.
>
> James
>
> —
> 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
>

It would be much better to just write it in a way which works correctly
in all environments, instead of using #ifdef. Why are you putting
addresses in an integer type? Why not just put them in a pointer, which
is what they are? would be an appropriate type for these
addresses, would work correctly in all environments, and would let you
get rid of some of the casts out of your code which is almost always a
good thing.

장경섭 wrote:
> Thank you very much Mr. James
>
> I could finish this terrible jobs because of your smart words!
>
> I could finish this job with #ifdef _WIN64
>
> Thank you very much again.
> Have a nice day. bye~
>
> 2011/7/15 James Harper > mailto:xxxxx>
>
> > UINT32 addrFrom, addrTo, transLength;
>
> You are using 32 bit UINT to hold a 64 bit address??? That’s never going
> to work.
>
> James</mailto:xxxxx>

That’s right! That’s what I really wanted!
Thank you very much Mr. Farrel. I’ll change my codes with (char *) address
pointer.

have a nice day. Bye~

2011/7/18 J. J. Farrell

> It would be much better to just write it in a way which works correctly in
> all environments, instead of using #ifdef. Why are you putting addresses in
> an integer type? Why not just put them in a pointer, which is what they are?
> would be an appropriate type for these addresses, would work
> correctly in all environments, and would let you get rid of some of the
> casts out of your code which is almost always a good thing.
>
> ???漷 wrote:
>
>> Thank you very much Mr. James
>> I could finish this terrible jobs because of your smart words!
>> I could finish this job with #ifdef _WIN64
>> Thank you very much again.
>> Have a nice day. bye~
>>
>> 2011/7/15 James Harper >> james.harper@ bendigoit.com.au >>
>>
>>
>> > UINT32 addrFrom, addrTo, transLength;
>>
>> You are using 32 bit UINT to hold a 64 bit address??? That’s never
>> going
>> to work.
>>
>> James
>>
>
> —
> 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=ListServerhttp:
></http:>

It is a common beginner’s error to use UINT32 as interchangeable with a
pointer, although the C and C++ standards themselves explicitly state this
is poor practice and is not guaranteed to ever work. This has not been
considered valid practice for many years, and to do so is a sure sign of
someone who is not an experienced programmer. The only correct declarations
(and without commas!) would be
UCHAR * addrFrom;
UCHAR * addrTo;
size_t transLength;

it is an equally serious error to think that size_t is 32 bits, and
therefore an integer is sufficient.

In application space, I see these errors all the time. I used to get paid
to fix them, before I retired.
joe


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of ???
Sent: Sunday, July 17, 2011 4:28 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] BSOD occurs when copy datas in Windows7 System Thread

Thank you very much Mr. James

I could finish this terrible jobs because of your smart words!

I could finish this job with #ifdef _WIN64

Thank you very much again.
Have a nice day. bye~
2011/7/15 James Harper
> UINT32 addrFrom, addrTo, transLength;

You are using 32 bit UINT to hold a 64 bit address??? That’s never going
to work.

James


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