Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging

The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.

Check out The OSR Learning Library at:

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

OSR_Community_UserOSR_Community_User Member Posts: 110,217
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*
OK 16 \\DESKTOP-E7JUPB3\symbols
Symbol search path is: srv*C:\Work\wt-vwt-win\symcache*;\\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 = 0xfffff800`01650000 PsLoadedModuleList = 0xfffff800`01895e90
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 *
* *

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.
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
Arg4: 0000000000000000, (reserved)

Debugging Details:

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

READ_ADDRESS: fffff80000000000

fffff800`00000000 ?? ???





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

LAST_CONTROL_TRANSFER: from 0000000000000000 to 0000000000000000

fffff800`00000000 ?? ???

00000000 00000000 00000000 00000000 00000000 0x0




MODULE_NAME: Unknown_Module

IMAGE_NAME: Unknown_Image






FAILURE_ID_HASH_STRING: km:invalid_kernel_context

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

Followup: MachineOwner


  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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
  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,356
    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.



  • Iolanda_MilaniIolanda_Milani Member - All Emails Posts: 17
    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.

    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.
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 7 Dec 2020 LIVE ONLINE
Internals & Software Drivers 25 Jan 2021 LIVE ONLINE
Developing Minifilters 8 March 2021 LIVE ONLINE