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

Home› NTFSD

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: https://www.osr.com/osr-learning-library/


PASSIVE_LEVEL and FLT_FILE_NAME_QUERY_DEFAULT not safe enough?

Doug_NDoug_N Member - All Emails Posts: 110
in NTFSD

According to my understanding of the docs, this should not happen. Since it is happening...

Code in a PostOp callback:

KIRQL irqLevel = KeGetCurrentIrql();
NTSTATUS status = 0;
PFLT_FILE_NAME_INFORMATION    pFileNameInformation = NULL;

    if ( (FlagOn(Data->Iopb->OperationFlags, SL_OPEN_PAGING_FILE)) || 
         (FlagOn(Flags, FLTFL_POST_OPERATION_DRAINING)) )
                return FLT_POSTOP_FINISHED_PROCESSING;

    if (PASSIVE_LEVEL == irqLevel) 
    {
         status = FltGetFileNameInformation(Data, FLT_FILE_NAME_OPENED | FLT_FILE_NAME_QUERY_DEFAULT, &pFileNameInformation);

The above line causes a crash with the following stack:

nt!DbgBreakPointWithStatus
nt!KiBugCheckDebugBreak+0x12
nt!KeBugCheck2+0x957
nt!KeBugCheckEx+0x107
nt!KiBugCheckDispatch+0x69
nt!KiSystemServiceHandler+0x7c
nt!RtlpExecuteHandlerForException+0xf
nt!RtlDispatchException+0x430
nt!KiDispatchException+0x144
nt!KiExceptionDispatch+0xc2
nt!KiPageFault+0x428
FLTMGR!FltGetFileNameInformation+0x7b
FLTMGR!FltvGetFileNameInformation+0x51
(code shown above in a PostOp function)
FLTMGR!FltpPerformPostMountCallbacks+0x90
FLTMGR!FltpFsControlMountVolume+0x2a5
FLTMGR!FltpFsControl+0x12c
nt!IopfCallDriver+0x56

This is on a fully patched Windows Server 2019. Are there additional cases to check for with FltGetFileNameInformation?

Thanks for any light you can share on this.

Doug

· Share on Facebook

Comments

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 506
    via Email
    What's the bugcheck and IRP path?
    This is not a simple PostOp, but a mount callback. Possibly aftet a
    format/lock combo.

    The call should not bugcheck, though, IMO, but return an error. I never
    tested/tried that path though.

    Dejan.
    · Share on Facebook
  • Doug_NDoug_N Member - All Emails Posts: 110

    Assuming I can trust what I see in WinDbg (I'm pretty sure this is a checked build), Iopb->MajorFunction is 0xED which I don't recognize. And FltObjects->FileObject is NULL. Maybe FltGetFileNameInformation doesn't handle the NULL FileObject? That might be the case from this output

    FLTMGR!FltGetFileNameInformation+7b
fffff802`d339553b 48395f18        cmp     qword ptr [rdi+18h],rbx

CONTEXT:  ffff808485a95070 -- (.cxr 0xffff808485a95070)
rax=0000000000000103 rbx=0000000000000000 rcx=0000000000000000
rdx=0000000000000102 rsi=0000000000000000 rdi=0000000000000000 #### looks to be null


    SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000005, Exception code that caused the bugcheck
Arg2: fffff802d339553b, Address of the instruction which caused the bugcheck
Arg3: ffff808485a95070, Address of the context record for the exception that caused the bugcheck
Arg4: 0000000000000000, zero.
    · Share on Facebook
  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 506
    via Email
    Mind sending the complete !analyze -v output?

    Looks more like a corruption to me, if MajorFunc is invalid.

    I am not sure if FGFNI handles NULL FO, but IMO it should at least not
    bugcheck :)

    Dejan.
    · Share on Facebook
  • Doug_NDoug_N Member - All Emails Posts: 110

    Sure, not a problem. Checking for NULL prevents the crash (not surprising I guess). Here is the full output with some more stack shown at the bottom. Drive name changed to protect the guilty :)

    1: kd> !analyze -v
Connected to Windows 10 17763 x64 target at (Thu Jan 12 12:15:26.008 2023 (UTC - 6:00)), ptr64 TRUE
Loading Kernel Symbols
...............................................................
................................................................
..............................
Loading User Symbols
.....................................................
Loading unloaded module list
................................................
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000005, Exception code that caused the bugcheck
Arg2: fffff80eb4cd553b, Address of the instruction which caused the bugcheck
Arg3: ffffc9053fb0d070, Address of the context record for the exception that caused the bugcheck
Arg4: 0000000000000000, zero.

Debugging Details:
------------------


KEY_VALUES_STRING: 1


PROCESSES_ANALYSIS: 1

SERVICE_ANALYSIS: 1

STACKHASH_ANALYSIS: 1

TIMELINE_ANALYSIS: 1


DUMP_CLASS: 1

DUMP_QUALIFIER: 0

BUILD_VERSION_STRING:  17763.1.amd64fre.rs5_release.180914-1434

DUMP_TYPE:  0

BUGCHECK_P1: c0000005

BUGCHECK_P2: fffff80eb4cd553b

BUGCHECK_P3: ffffc9053fb0d070

BUGCHECK_P4: 0

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

FAULTING_IP: 
FLTMGR!FltGetFileNameInformation+7b
fffff80e`b4cd553b 48395f18        cmp     qword ptr [rdi+18h],rbx

CONTEXT:  ffffc9053fb0d070 -- (.cxr 0xffffc9053fb0d070)
rax=0000000000000103 rbx=0000000000000000 rcx=0000000000000000
rdx=0000000000000102 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80eb4cd553b rsp=ffffc9053fb0da60 rbp=00000000000000ed
 r8=ffffc9053fb0db58  r9=ffffce0f2c999ba0 r10=ffffce0f2d10cea0
r11=ffffce0f2cf61550 r12=0000000000000102 r13=ffffc9053fb0db58
r14=ffffce0f2c999b48 r15=fffff80eb4cec4e3
iopl=0         nv up ei pl zr na po nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
FLTMGR!FltGetFileNameInformation+0x7b:
fffff80e`b4cd553b 48395f18        cmp     qword ptr [rdi+18h],rbx ds:002b:00000000`00000018=????????????????
Resetting default scope

BUGCHECK_STR:  0x3B_c0000005

CPU_COUNT: 4

CPU_MHZ: d50

CPU_VENDOR:  GenuineIntel

CPU_FAMILY: 6

CPU_MODEL: 5e

CPU_STEPPING: 3

CPU_MICROCODE: 6,5e,3,0 (F,M,S,R)  SIG: FFFFFFFF'00000000 (cache) FFFFFFFF'00000000 (init)

DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

PROCESS_NAME:  svchost.exe

CURRENT_IRQL:  0

ANALYSIS_SESSION_HOST:  D2

ANALYSIS_SESSION_TIME:  01-12-2023 12:15:29.0530

ANALYSIS_VERSION: 10.0.18362.1 amd64fre

LAST_CONTROL_TRANSFER:  from fffff80eb4d2e451 to fffff80eb4cd553b

STACK_TEXT:  
ffffc905`3fb0da60 fffff80e`b4d2e451 : ffffce0f`2b11f010 ffffce0f`2b11f010 ffffc905`3fb0e201 fffff804`00000001 : FLTMGR!FltGetFileNameInformation+0x7b
ffffc905`3fb0dae0 fffff804`80112851 : ffffce0f`2c999a60 00000000`00000000 fffff804`8011b093 ffffce0f`2c1c3860 : FLTMGR!FltvGetFileNameInformation+0x51
ffffc905`3fb0db10 fffff804`80116673 : ffffce0f`2c999b48 fffff804`8011b470 fffff804`80ef6fc0 ffffc905`3fb0e040 : MYDRIVER!LogToDbgPrintWithFileName+0x141 
ffffc905`3fb0df90 fffff804`80116cc9 : ffffce0f`2c999b48 ffffc905`3fb0f0a0 00000000`00000000 ffffce0f`00000000 : MYDRIVER!RCPostOperationCallback+0x73 
ffffc905`3fb0e030 fffff80e`b4d1292c : ffffce0f`2c999b48 ffffc905`3fb0f0a0 00000000`00000000 ffffce0f`00000000 : MYDRIVER!PostOperationCallback+0x1a9 
ffffc905`3fb0f070 fffff80e`b4d124e9 : 00000000`c0000013 ffffce0f`2d0b7920 ffffce0f`2d2ec060 ffffce0f`29ed8010 : FLTMGR!FltpPerformPostMountCallbacks+0x90
ffffc905`3fb0f0e0 fffff80e`b4d0cb8c : ffffce0f`2a902c10 fffff804`c0000013 00000000`00000000 ffffce0f`2c8ca0a0 : FLTMGR!FltpFsControlMountVolume+0x2a5
ffffc905`3fb0f1d0 fffff804`80c2b63a : ffffce0f`2d0b7920 00000000`00000001 ffffce0f`2a902c10 ffffce0f`00000000 : FLTMGR!FltpFsControl+0x12c
ffffc905`3fb0f230 fffff804`813def49 : ffffce0f`2d0b7920 ffffce0f`2a902c10 fffff804`80eef8e0 fffff804`80ae39de : nt!IopfCallDriver+0x56
ffffc905`3fb0f270 fffff804`80c9f4c7 : ffffce0f`2a902c10 ffffc905`3fb0f3a1 fffff804`80eef8e0 ffffce0f`2cf629a0 : nt!IovCallDriver+0x275
ffffc905`3fb0f2b0 fffff804`810ea31d : ffffce0f`2a4248f0 ffffc905`3fb0f3a1 ffffce0f`2a185940 fffff804`80eef8e0 : nt!IofCallDriver+0x1b74f7
ffffc905`3fb0f2f0 fffff804`80ae1353 : 00000001`00000001 ffffce0f`2a8d6220 00000000`00000000 ffffad2a`b7b77597 : nt!IopMountVolume+0x31d
ffffc905`3fb0f400 fffff804`81086f3f : 00000000`00000085 00000000`00000000 ffffc905`3fb0f6d0 00000000`00000000 : nt!IopCheckVpbMounted+0x1b3
ffffc905`3fb0f460 fffff804`8108ff29 : ffffce0f`2a4248f0 ffffce0f`2a4248c0 ffffce0f`2d662520 ffffe587`08ec0e01 : nt!IopParseDevice+0x8ff
ffffc905`3fb0f5d0 fffff804`8108ea2f : ffffce0f`2d662500 ffffc905`3fb0f838 00000000`00000040 ffffce0f`26f134e0 : nt!ObpLookupObjectName+0x719
ffffc905`3fb0f7a0 fffff804`8106cafd : ffffc905`00000001 000000a5`aa3fe450 00000000`00000001 00000000`00004021 : nt!ObOpenObjectByNameEx+0x1df
ffffc905`3fb0f8e0 fffff804`8106c438 : 000000a5`aa3fe428 00000000`00100000 000000a5`aa3fe450 000000a5`aa3fe440 : nt!IopCreateFile+0x61d
ffffc905`3fb0f980 fffff804`80c86ff5 : 00000000`00000400 00000000`00000000 00000000`00000000 00000000`00000000 : nt!NtOpenFile+0x58
ffffc905`3fb0fa10 00007ffc`f59b0e54 : 00007ffc`f1b34536 00000232`05eb7c60 000000a5`aa3fee00 00000000`00000027 : nt!KiSystemServiceCopyEnd+0x25
000000a5`aa3fe3d8 00007ffc`f1b34536 : 00000232`05eb7c60 000000a5`aa3fee00 00000000`00000027 00007ffc`dfda2be6 : ntdll!NtOpenFile+0x14
000000a5`aa3fe3e0 00007ffc`dfdd1ef8 : 00000000`00000000 000000a5`aa3fee00 00000232`05eb7c60 000000a5`aa3fed38 : KERNELBASE!GetVolumeInformationW+0xd6
000000a5`aa3fe4a0 00007ffc`dfdd18d0 : 00000000`00000000 000000a5`aa3ff190 00000000`00000000 00000000`00000003 : sdprov!cmn::QueryVolumeInfoObject+0x1d0
000000a5`aa3fed00 00007ffc`dfdc9b8e : 00000232`04007dd0 00000232`040149e0 00000000`00000032 00007ffc`dfdd40f8 : sdprov!cmn::EnumVolumesAndQueryVolumeInfoObjects+0xcc
000000a5`aa3ff090 00007ffc`dfdca100 : 00000000`00000000 00000000`00000000 00000232`040149e0 00000000`00000000 : sdprov!sdp::SruVolumeProvider::QueryStats+0x6e
000000a5`aa3ff290 00007ffc`dfea13f5 : 00000232`040082c0 00000232`040082c0 00000232`040082c0 000000a5`aa3ff410 : sdprov!sdp::QueryStatsEx+0x90
000000a5`aa3ff380 00007ffc`dfea1100 : 00000232`00000000 00000000`00000000 00000232`03fc7b48 00000000`00000000 : srumsvc!SruStatsUpdateStores+0x245
000000a5`aa3ff470 00007ffc`dfea23ce : 00000232`04008428 00000232`05d474e0 00000232`03fe5390 000000a5`aa3ff6b8 : srumsvc!SruWorkItemQueryProvider+0x80
000000a5`aa3ff4c0 00007ffc`f597bb90 : 00000232`04012cf0 00000232`04012db8 00000232`05d474e0 00000000`00000000 : srumsvc!SruWorkQueueThreadPoolCallback+0xfe
000000a5`aa3ff500 00007ffc`f5926964 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000010 : ntdll!TppWorkpExecuteCallback+0x130
000000a5`aa3ff550 00007ffc`f3587ad4 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!TppWorkerThread+0x644
000000a5`aa3ff840 00007ffc`f596a371 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : KERNEL32!BaseThreadInitThunk+0x14
000000a5`aa3ff870 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x21


THREAD_SHA1_HASH_MOD_FUNC:  a5cc8f1136917a5e11f2181585704b591118414c

THREAD_SHA1_HASH_MOD_FUNC_OFFSET:  0f3aac9e769ec3afe2079931775a6e5f1ac525fd

THREAD_SHA1_HASH_MOD:  d2653f49bae8b1749f9f8658ab5e20566350e50d

FOLLOWUP_IP: 
MYDRIVER!LogToDbgPrintWithFileName+141
fffff804`80112851 89442454        mov     dword ptr [rsp+54h],eax

FAULT_INSTR_CODE:  54244489

FAULTING_SOURCE_LINE:  mf.c

FAULTING_SOURCE_FILE:  mf.c

FAULTING_SOURCE_LINE_NUMBER:  2043

SYMBOL_STACK_INDEX:  2

SYMBOL_NAME:  MYDRIVER!LogToDbgPrintWithFileName+141

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: MYDRIVER

IMAGE_NAME:  MYDRIVER.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  63c04de8

STACK_COMMAND:  .cxr 0xffffc9053fb0d070 ; kb

BUCKET_ID_FUNC_OFFSET:  141

FAILURE_BUCKET_ID:  0x3B_c0000005_VRF_MYDRIVER!LogToDbgPrintWithFileName

BUCKET_ID:  0x3B_c0000005_VRF_MYDRIVER!LogToDbgPrintWithFileName

PRIMARY_PROBLEM_CLASS:  0x3B_c0000005_VRF_MYDRIVER!LogToDbgPrintWithFileName

TARGET_TIME:  2023-01-12T18:15:09.000Z

OSBUILD:  17763

OSSERVICEPACK:  0

SERVICEPACK_NUMBER: 0

OS_REVISION: 0

SUITE_MASK:  272

PRODUCT_TYPE:  3

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

OSEDITION:  Windows 10 Server TerminalServer SingleUserTS

OS_LOCALE:  

USER_LCID:  0

OSBUILD_TIMESTAMP:  unknown_date

BUILDDATESTAMP_STR:  180914-1434

BUILDLAB_STR:  rs5_release

BUILDOSVER_STR:  10.0.17763.1.amd64fre.rs5_release.180914-1434

ANALYSIS_SESSION_ELAPSED_TIME:  d9c7

ANALYSIS_SOURCE:  KM

FAILURE_ID_HASH_STRING:  km:0x3b_c0000005_vrf_MYDRIVER!logtodbgprintwithfilename

FAILURE_ID_HASH:  {0a4ecf97-c93c-8c12-e1ef-b60409191a06}

Followup:     MachineOwner
---------
    · Share on Facebook
  • Doug_NDoug_N Member - All Emails Posts: 110

    Hmmm, for some reason the extra stack I'm trying to post isn't showing up right. I guess I won't mark it as code...

    # Child-SP RetAddr : Args to Child : Call Site
    00 ffffc9053fb0bf78 fffff80480d4b582 : 00000000c0000005 0000000000000003 ffffc9053fb0c0e0 fffff80480c19ab0 : nt!DbgBreakPointWithStatus
    01 ffffc9053fb0bf80 fffff80480d4ad07 : 0000000000000003 ffffc9053fb0c0e0 fffff80480c8a3e0 000000000000003b : nt!KiBugCheckDebugBreak+0x12
    02 ffffc9053fb0bfe0 fffff80480c73fa7 : fffff804164ae8c3 fffff804816198cf ffffc9053fb0fa80 fffff80481623508 : nt!KeBugCheck2+0x957
    03 ffffc9053fb0c700 fffff80480c87829 : 000000000000003b 00000000c0000005 fffff80eb4cd553b ffffc9053fb0d070 : nt!KeBugCheckEx+0x107
    04 ffffc9053fb0c740 fffff80480c86a3c : ffffc9053fb0d828 ffffc9053fb0d070 ffffc9053fb0d828 0000000000000000 : nt!KiBugCheckDispatch+0x69
    05 ffffc9053fb0c880 fffff80480c7e1df : fffff80480f9c000 fffff80480abb000 0005b02000a6d000 000000000010001f : nt!KiSystemServiceHandler+0x7c
    06 ffffc9053fb0c8c0 fffff80480b3a990 : ffffc9053fb0cf10 0000000000000000 ffffc9053fb0ce30 fffff80480e4a10c : nt!RtlpExecuteHandlerForException+0xf
    07 ffffc9053fb0c8f0 fffff80480b3cc94 : ffffc9053fb0d828 ffffc9053fb0d570 ffffc9053fb0d828 0000000000000000 : nt!RtlDispatchException+0x430
    08 ffffc9053fb0d040 fffff80480c87902 : 0000000000000000 ffffc9053fb0d8d0 0000000000001000 0000000000000018 : nt!KiDispatchException+0x144
    09 ffffc9053fb0d6f0 fffff80480c834e8 : ffffad2ab7b75187 fffff80480bd5117 fffff80400000000 0000000000000004 : nt!KiExceptionDispatch+0xc2
    0a ffffc9053fb0d8d0 fffff80eb4cd553b : 0000000000000000 fffff80480a1faf6 ffffce0f2d10cea0 fffff80eb4cd2c8b : nt!KiPageFault+0x428 (TrapFrame @ ffffc9053fb0d8d0) 0b ffffc9053fb0da60 fffff80eb4d2e451 : ffffce0f2b11f010 ffffce0f2b11f010 ffffc9053fb0e201 fffff80400000001 : FLTMGR!FltGetFileNameInformation+0x7b 0c ffffc9053fb0dae0 fffff80480112851 : ffffce0f2c999a60 0000000000000000 fffff8048011b093 ffffce0f2c1c3860 : FLTMGR!FltvGetFileNameInformation+0x51 0d ffffc9053fb0db10 fffff80480116673 : ffffce0f2c999b48 fffff8048011b470 fffff80480ef6fc0 ffffc9053fb0e040 : MYDRIVER!LogToDbgPrintWithFileName(struct _FLT_CALLBACK_DATA * Data = 0xffffce0f2c999b48, char * str = 0xfffff8048011b470 "PAFS: RCPost with ")+0x141 0e ffffc9053fb0df90 fffff80480116cc9 : ffffce0f2c999b48 ffffc9053fb0f0a0 0000000000000000 ffffce0f00000000 : MYDRIVER!RCPostOperationCallback(struct _FLT_CALLBACK_DATA * Data = 0xffffce0f2c999b48, struct _FLT_RELATED_OBJECTS * FltObjects = 0xffffc9053fb0f0a0, void * CompletionContext = 0x0000000000000000, unsigned long Flags = 0)+0x73
    0f ffffc9053fb0e030 fffff80eb4d1292c : ffffce0f2c999b48 ffffc9053fb0f0a0 0000000000000000 ffffce0f00000000 : MYDRIVER!PostOperationCallback(struct _FLT_CALLBACK_DATA * Data = 0xffffce0f2c999b48, struct _FLT_RELATED_OBJECTS * FltObjects = 0xffffc9053fb0f0a0, void * CompletionContext = 0x0000000000000000, unsigned long Flags = 0)+0x1a9 10 ffffc9053fb0f070 fffff80eb4d124e9 : 00000000c0000013 ffffce0f2d0b7920 ffffce0f2d2ec060 ffffce0f29ed8010 : FLTMGR!FltpPerformPostMountCallbacks+0x90 11 ffffc9053fb0f0e0 fffff80eb4d0cb8c : ffffce0f2a902c10 fffff804c0000013 0000000000000000 ffffce0f2c8ca0a0 : FLTMGR!FltpFsControlMountVolume+0x2a5 12 ffffc9053fb0f1d0 fffff80480c2b63a : ffffce0f2d0b7920 0000000000000001 ffffce0f2a902c10 ffffce0f00000000 : FLTMGR!FltpFsControl+0x12c 13 ffffc9053fb0f230 fffff804813def49 : ffffce0f2d0b7920 ffffce0f2a902c10 fffff80480eef8e0 fffff804`80ae39de : nt!IopfCallDriver+0x56

    · Share on Facebook
  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 506
    via Email
    Ye, the stack agrees that address 0x18 was accessed, which caused the
    bugcheck. That would be FsContext.

    I would have thought FGFNI could handle (with an error code) such a case
    (where FO is NULL), but seems not. Maybe that is why I added
    IgnoreIfFSIsNull in CREATE two decades ago :)

    To answer your original question, FGFNI is safe to call in your test cade;
    it should simply return an error if if should not be called, as long as
    Data is not corrupted.
    This seems like another case, that needs adding, in the list of 200KB of
    FGFNI workaround code that I already have :D

    You could test if it fails for opening of the volume in PreCreate? It
    should be a NULL FO IIRC, so calling FGFNI would bugcheck here also? Not
    sure about this, it was 2 decades or so since I started adding ignoring of
    NULL FO in any of my code.

    Regards, Dejan.
    · Share on Facebook
  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,527

    This is an IRP_MJ_VOLUME_MOUNT:

    #define IRP_MJ_VOLUME_MOUNT ((UCHAR)-19)

    There's no File Object for this operation (and no name) so just don't call FGFNI.

    -scott
    OSR

    · Share on Facebook
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Sign In Register
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!
Kernel Debugging 30 January 2023 Live, Online
Developing Minifilters 20 March 2023 Live, Online
Internals & Software Drivers 17 April 2023 Live, Online
Writing WDF Drivers 22 May 2023 Live, Online

Categories