Bug Check in hooking NtProtectVirtualMemory & NtMapViewOfSection

[leeqwind]

Hey! I met a bug check (DRIVER_VERIFIER_DETECTED_VIOLATION) when hooking NtProtectVirtualMemory & NtMapViewOfSection APIs. I tested it in Windows 7 SP1 x64, and hooked NtProtectVirtualMemory by its SSDT index (77) hardcode in the source code. It didn't cause BSOD at once, but several minutes later, it happened.

It won't cause BSOD either if I hook any of them alone. I don't know if there are some other APIs can result in such a condition.

DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught.  This is
because the driver was specified in the registry as being suspect (by the
administrator) and the kernel has enabled substantial checking of this driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA will
be among the most commonly seen crashes.
Arguments:
Arg1: 00000091, A driver switched stacks using a method that is not supported by
	the operating system. The only supported way to extend a kernel
	mode stack is by using KeExpandKernelStackAndCallout.
Arg2: 00000002
Arg3: 018e9b60
Arg4: 00000000

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


DUMP_CLASS: 1

DUMP_QUALIFIER: 401

BUILD_VERSION_STRING:  7601.17514.amd64fre.win7sp1_rtm.101119-1850

SYSTEM_MANUFACTURER:  VMware, Inc.

VIRTUAL_MACHINE:  VMware

SYSTEM_PRODUCT_NAME:  VMware Virtual Platform

SYSTEM_VERSION:  None

BIOS_VENDOR:  Phoenix Technologies LTD

BIOS_VERSION:  6.00

BIOS_DATE:  07/02/2015

BASEBOARD_MANUFACTURER:  Intel Corporation

BASEBOARD_PRODUCT:  440BX Desktop Reference Platform

BASEBOARD_VERSION:  None

DUMP_TYPE:  1

BUGCHECK_P1: 91

BUGCHECK_P2: 2

BUGCHECK_P3: fffffa80018e9b60

BUGCHECK_P4: 0

BUGCHECK_STR:  0xc4_91

CPU_COUNT: 1

CPU_MHZ: e11

CPU_VENDOR:  GenuineIntel

CPU_FAMILY: 6

CPU_MODEL: 3c

CPU_STEPPING: 3

CPU_MICROCODE: 6,0,0,0 (F,M,S,R)  SIG: 1E'00000000 (cache) 1E'00000000 (init)

CURRENT_IRQL:  0

ANALYSIS_SESSION_HOST:  LIQI3-S-D8

ANALYSIS_SESSION_TIME:  06-09-2017 17:54:29.0797

ANALYSIS_VERSION: 10.0.14321.1024 amd64fre

IP_IN_FREE_BLOCK: 0

LAST_CONTROL_TRANSFER:  from 00000000 to 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

BUCKET_ID:  INVALID_KERNEL_CONTEXT_0xc4_91

DEFAULT_BUCKET_ID:  INVALID_KERNEL_CONTEXT_0xc4_91

PRIMARY_PROBLEM_CLASS:  INVALID_KERNEL_CONTEXT

FAILURE_BUCKET_ID:  INVALID_KERNEL_CONTEXT_0xc4_91

TARGET_TIME:  2017-06-09T09:50:23.000Z

OSBUILD:  7601

OSSERVICEPACK:  1000

SERVICEPACK_NUMBER: 0

OS_REVISION: 0

SUITE_MASK:  272

PRODUCT_TYPE:  1

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 7

OSEDITION:  Windows 7 WinNt (Service Pack 1) TerminalServer SingleUserTS

OS_LOCALE:  

USER_LCID:  0

OSBUILD_TIMESTAMP:  2010-11-20 17:30:02

BUILDDATESTAMP_STR:  101119-1850

BUILDLAB_STR:  win7sp1_rtm

BUILDOSVER_STR:  6.1.7601.17514.amd64fre.win7sp1_rtm.101119-1850

ANALYSIS_SESSION_ELAPSED_TIME: 37a

ANALYSIS_SOURCE:  KM

FAILURE_ID_HASH_STRING:  km:invalid_kernel_context_0xc4_91

FAILURE_ID_HASH:  {c8fab66e-0b86-6ef2-c0d0-229ea9ea76fc}

Followup:     MachineOwner
---------

[leeqwind]

Ii seems that the BSOD is caused just if the OS boot in non-kernel-debug mode.

[tandasat]

Hey, can you share any of those information? or, stack trace on the bug check.

• a Debug build version of a compiled SYS file and a PDB file
• a full set of source code used to build the SYS file if it has been modified
• a log file (i.e., C:\Windows\HyperPlatform.log)
• a system crash dump file (i.e., C:\Windows\MEMORY.DMP)

Also, please check if DriverVerifier is applied to any drivers.

[leeqwind]

@tandasat Okay, these files have been uploaded to Microsoft OneDrive: https://1drv.ms/f/s!ApQpgQkWR0QOi7g5IXa7c0agVIFEYw

• DdiMon.sys & DdiMon.pdb
• DdiMon.log
• MEMORY.zip: the zip package of MEMORY.DMP file.
• DdiMon_Code.zip: the modified source code of DdiMon project.

I just modified ddi_mon.cpp file by adding some functions about SSDT and 2 entries for g_ddimonp_hook_targets array.

The stack trace on the bug check is:

16.kd:x86> kv
 # ChildEBP          RetAddr           Args to Child                                         
WARNING: Frame IP not in any known module. Following frames may be wrong.
00 00000000 00000000 00000000 00000000 00000000 0x0

Thank you!

[leeqwind]

I have set none of the drivers into DriverVerifier before, it keeps the default configuration.

[tandasat]

Thank you for collecting files. I have downloaded them. I will find time to look into it.

[hzqst]

tandasat/HyperPlatform#4
HyperPlatform do not support run with DriverVerifier for now.

[tandasat]

It’s true that HyperPlatform is not compatible with DriverVerifier but the issue is unrelated to DriverVerifier if I understand this correctly.

[leeqwind]

@tandasat @hzqst Yes this issue is unrelated to DriverVerifier.

[tandasat]

@leeqwind Sorry for taking very time. I had a chance to touch DdiMon code recently and tried to reproduce the issue by running DdiMon with the patch on two Win7 VMs for some time. However, I have not been unable to see the issue. Few things to ask you:

• Can you try with the latest commit of DdiMon and HyperPlatform?
• Can you try on a physical machine (not on VMware)?
• Does this still repro on your side consistently?

The uploaded dump file shows that all registers (including CR3 and segment selectors) are all zero. I cannot think of how this could happen if the dump file is not broken (indeed the file looks valid). My suspicion is that you hit some VMware bug related to nested virtualization.

[tandasat]

I close this since it has been 3 weeks without update. Please re-open the issue if it still relevant.