help needed: BSOD-0x50,with arg2=0x8 and same value for arg1/arg3

thanks advance for any assistance, im googled/OSRed serveral days, no simliarity / clue found till now…

Loading Dump File [D:\work2\MEMORY.DMP]
Kernel Summary Dump File: Only kernel address space is available

************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred srv*C:\Work\wt-vwt-win\symcache*http://msdl.microsoft.com/download/symbols
OK 16 \DESKTOP-E7JUPB3\symbols
Symbol search path is: srv*C:\Work\wt-vwt-win\symcache*http://msdl.microsoft.com/download/symbols;\\DESKTOP-E7JUPB3\symbols
Executable search path is:
Windows 7 Kernel Version 7601 (Service Pack 1) UP Free x64
Product: Server, suite: TerminalServer SingleUserTS
Built by: 7601.17514.amd64fre.win7sp1_rtm.101119-1850
Machine Name:
Kernel base = 0xfffff80001650000 PsLoadedModuleList = 0xfffff80001895e90
Debug session time: Tue Dec 12 21:34:44.059 2017 (UTC + 8:00)
System Uptime: 0 days 0:00:10.531
Loading Kernel Symbols


Loading User Symbols
PEB is paged out (Peb.Ldr = 00000000`7efdf018). Type “.hh dbgerr001” for details
Loading unloaded module list

The context is partially valid. Only x86 user-mode context is available.
The wow64exts extension must be loaded to access 32-bit state.
.load wow64exts will do this if you haven’t loaded it already.
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 50, {fffff80000000000, 8, fffff80000000000, 0}

Page 799b2 not present in the dump file. Type “.hh dbgerr004” for details
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )

Followup: MachineOwner

16.kd:x86> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: fffff80000000000, memory referenced.
Arg2: 0000000000000008, value 0 = read operation, 1 = write operation.
Arg3: fffff80000000000, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 0000000000000000, (reserved)

Debugging Details:

Page 799b2 not present in the dump file. Type “.hh dbgerr004” for details

READ_ADDRESS: fffff80000000000

FAULTING_IP:
+d131b7d600
fffff800`00000000 ?? ???

MM_INTERNAL_CODE: 0

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

BUGCHECK_STR: 0x50

CURRENT_IRQL: 0

ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) amd64fre

LAST_CONTROL_TRANSFER: from 0000000000000000 to 0000000000000000

FAILED_INSTRUCTION_ADDRESS:
+d131b7d600
fffff800`00000000 ?? ???

STACK_TEXT:
00000000 00000000 00000000 00000000 00000000 0x0

STACK_COMMAND: kb

SYMBOL_NAME: ANALYSIS_INCONCLUSIVE

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Unknown_Module

IMAGE_NAME: Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP: 0

IMAGE_VERSION:

BUCKET_ID: INVALID_KERNEL_CONTEXT

FAILURE_BUCKET_ID: INVALID_KERNEL_CONTEXT

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:invalid_kernel_context

FAILURE_ID_HASH: {ef5f68ed-c19c-e34b-48ec-8a37cd6f3937}

Followup: MachineOwner

the latest windbg log shows: it crashed with bsod50, when the executed and read is the same file…

did someone meet similiarity? thanks a lot

merry chrismas to all

Your instruction pointer is trashed, probably a stack overflow of some kind.
You can try dumping the pre-bugcheck stack save area and see if you can
reconstruct the surrounding call stack:

dps nt!KiPreBugcheckStackSaveArea L6000/8

Other than that, start adding tracing to your code and figure out the last
functions called before the crash.

-scott
OSR
@OSRDrivers

Check the call stack to help you identify the routines called leading up to the bug-check. The issue allegedly is due to accessing memory which has already been free’d. If it’s related to your own device driver, check to see if you’re calling ExFreePoolWithTag (ExFreePool calls that routine) and then accessing the memory which you had previously free’d in routines shown from a call stack listing.

If you free memory, then you can’t start referencing with it… Because the address would become invalid. You can also make use of MmIsAddressValid for additional checks to help prevent bug-checks.

https://msdn.microsoft.com/en-us/library/windows/hardware/ff554572(v=vs.85).aspx

I am not sure how reputable or good MmIsAddressValid is, but I tend to use it sometimes. Then again, using it won’t automatically prevent your own mistakes from causing a bug-check. It might help, but if you’re freeing memory and then trying to use it, you’re going to land into trouble with the kernel.