Thursday, February 16, 2017

What a BSOD!


APC_INDEX_MISMATCH (1)
This is a kernel internal error. The most common reason to see this
bugcheck is when a filesystem or a driver has a mismatched number of
calls to disable and re-enable APCs. The key data item is the
Thread->CombinedApcDisable field. This consists of two separate 16-bit
fields, the SpecialApcDisable and the KernelApcDisable. A negative value
of either indicates that a driver has disabled special or normal APCs
(respectively) without re-enabling them; a positive value indicates that
a driver has enabled special or normal APCs (respectively) too many times.
Arguments:
Arg1: 00007ffeb44461b4, Address of system call function or worker routine
Arg2: 0000000000000000, Thread->ApcStateIndex
Arg3: 000000000000ffff, (Thread->SpecialApcDisable << 16) | Thread->KernelApcDisable
Arg4: ffffc6816b407b80, Call type (0 - system call, 1 - worker routine)

Sunday, January 29, 2017

Current process when closing a kernel handle.

If you call PsGetCurrentProcess() in a filter or driver when processing IRP_MJ_CLEANUP for a kernel handle the system process is returned as NtClose() calls KeStackAttachProcess() if the handle belongs to a system process kernel table.

2: kd> !thread ffffc5006e6da080
THREAD ffffc5006e6da080  Cid 1588.05ec  Teb: 00000000002aa000 Win32Thread: 0000000000000000 WAIT: (WrResource) KernelMode Non-Alertable
    ffffc5006be8eb70  SynchronizationEvent
IRP List:
    ffffc5006e2ba140: (0006,04c0) Flags: 00000404  Mdl: 00000000
    ffffc50075b8aae0: (0006,0118) Flags: 00060000  Mdl: 00000000
Not impersonating
DeviceMap                 ffffd58256416bd0
Owning Process            ffffc500733ff080       Image:         XXXXXXXX
Attached Process          ffffc5006b8b66c0       Image:        System

Wednesday, January 25, 2017

Microsoft Security Essentials content scan callback to the service.

Below is a stack when a MSE file system filter(WdFilter.sys) called a service(MsMpEng.exe) to perform file content scan on file open.


00 nt!KiSwapContext
01 nt!KiSwapThread
02 nt!KiCommitThreadWait
03 nt!KeWaitForMultipleObjects
04 nt!FsRtlCancellableWaitForMultipleObjects
05 FLTMGR!FltSendMessage
06 WdFilter!MpScanFile
07 WdFilter!MpAmPostCreate
08 WdFilter!MpPostCreate
09 FLTMGR!FltpPerformPostCallbacks
0a FLTMGR!FltpPassThroughCompletionWorker
0b FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted
0c FLTMGR!FltpCreate
16 nt!IopParseDevice
17 nt!ObpLookupObjectName
18 nt!ObOpenObjectByNameEx
19 nt!IopCreateFile
1a nt!NtCreateFile
1b nt!KiSystemServiceCopyEnd
1c ntdll!NtCreateFile



In response the service sent an IOCTL to the filter to create a section( i.e. a mapped file) for data scan

0b mup!MupStateMachine
0c mup!MupFsControl
0d FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted
0e FLTMGR!FltPerformSynchronousIo
0f FLTMGR!IssueControlOperation
10 FLTMGR!FltFsControlFile
11 FLTMGR!FltpSetPurgeFailureMode
12 FLTMGR!FltCreateSectionForDataScan
13 WdFilter!MpCreateSection
14 WdFilter!MpMessage
15 FLTMGR!FltpFilterMessage
16 FLTMGR!FltpMsgDispatch
17 FLTMGR!FltpDispatch
21 nt!IopSynchronousServiceTail
22 nt!IopXxxControlFile
23 nt!NtDeviceIoControlFile
24 nt!KiSystemServiceCopyEnd
25 ntdll!NtDeviceIoControlFile


Friday, January 20, 2017

Initramfs population.

Did you ever wonder how initramfs is populated on Linux kernel startup? Look at the screnshots below ( click to see in full size ).










Thursday, January 12, 2017

Sunday, January 8, 2017

Setting Irp->UserIosb for unsuccessful requests.

Just for the record.

Irp->IoStatus is not copied to Irp->UserIosb by the special kernel mode APC , i.e.  IopCompleteRequest, on Irp completion if NT_ERROR(Irp->IoStatus.Status) is true and the Irp is synchronous or has not been made pending. This is important when returning any information in Irp->IoStatus.Information for unsuccessful requests when Irp->Flags doesn't have the IRP_BUFFERED_IO flag set. To indicate that the data has not been returned and provide an additional information in Irp->UserIosb.Information use a special status like STATUS_BUFFER_OVERFLOW which is not an error code.  If the IRP_BUFFERED_IO flag is set you can't use the Information field for an unsuccessful request as the system will try to copy data from Irp->AssociatedIrp.SystemBuffer to Irp->UserBuffer in case of NT_ERROR(Irp->IoStatus.Status) is not being true.