Could mfehidk.sys cause RDP issues?

[Edgar1210]

Hello All, we currently had a situation on where a server was unreachable through RDP. Upon digging into this it was noticed that the possible cause of this issue was mfehidk.sys(due to some logs)

I would highly appreciate if somebody could tell me if mfehidk.sys could affect a server in this way.

And if not, I would also appreciate if you could share information on what issues are related to mfehidk.sys and why this process could produce negative effects on a server.

Thank you.

[mbuehler]

Hi @Edgar1210,

mfehidk.sys is our disk filter driver, not our NDIS driver, so it's unlikely that it directly caused the issue you were seeing. We don't have any issues that I'm aware of directly related to mfehidk affecting RDP. What logs did you review that pointed to hidk as being the culprit?

Additionally - Did this happen directly after installing VSE, or was it after VSE had been installed for some time?

Thank you,

[Edgar1210]

Thank you for your prompt response @mbuehler,

VSE was already installed.

This was a situation handled by the Server Team. I will ask them for the logs so I can share them with you.

I believe your answer will be more than enough, however I will wait on their response to corroborate if further investigation will be needed. I will reply back as soon as possible.

[Edgar1210]

Hi All, since I am not able to attach .txt I will paste the analysis information here. Hope it doesn't bother you.

.....
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 8E, {c0000005, 8173356d, 8f267b94, 0}

Page 1307d9 not present in the dump file. Type ".hh dbgerr004" for details
Page 1307d9 not present in the dump file. Type ".hh dbgerr004" for details
*** ERROR: Module load completed but symbols could not be loaded for mfehidk.sys
Page 1307d9 not present in the dump file. Type ".hh dbgerr004" for details
Probably caused by : mfehidk.sys ( mfehidk+5733f )

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

3: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 8173356d, The address that the exception occurred at
Arg3: 8f267b94, Trap Frame
Arg4: 00000000

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

Page 1307d9 not present in the dump file. Type ".hh dbgerr004" for details
Page 1307d9 not present in the dump file. Type ".hh dbgerr004" for details

DUMP_CLASS: 1

DUMP_QUALIFIER: 401

BUILD_VERSION_STRING: 6003.20597.x86fre.vistasp2_ldr_escrow.190806-2021

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: 09/17/2015

BASEBOARD_MANUFACTURER: Intel Corporation

BASEBOARD_PRODUCT: 440BX Desktop Reference Platform

BASEBOARD_VERSION: None

DUMP_TYPE: 1

BUGCHECK_P1: ffffffffc0000005

BUGCHECK_P2: ffffffff8173356d

BUGCHECK_P3: ffffffff8f267b94

BUGCHECK_P4: 0

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

FAULTING_IP:
win32k!xxxDestroyThreadInfo+674
8173356d 8b08 mov ecx,dword ptr [eax]

TRAP_FRAME: 8f267b94 -- (.trap 0xffffffff8f267b94)
ErrCode = 00000000
eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=ffa03960 edi=818800e8
eip=8173356d esp=8f267c08 ebp=8f267c50 iopl=0 nv up ei pl nz na pe cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010207
win32k!xxxDestroyThreadInfo+0x674:
8173356d 8b08 mov ecx,dword ptr [eax] ds:0023:00000000=????????
Resetting default scope

CPU_COUNT: 8

CPU_MHZ: bba

CPU_VENDOR: GenuineIntel

CPU_FAMILY: 6

CPU_MODEL: 1a

CPU_STEPPING: 4

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

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x8E

PROCESS_NAME: csrss.exe

CURRENT_IRQL: 0

ANALYSIS_SESSION_HOST: HCPYRK1VSCTERM

ANALYSIS_SESSION_TIME: 11-18-2019 10:46:36.0072

ANALYSIS_VERSION: 10.0.10586.567 amd64fre

LAST_CONTROL_TRANSFER: from 81e8405d to 81e7b810

STACK_TEXT:
8f267c50 81732885 00000001 8f267c78 817327b1 win32k!xxxDestroyThreadInfo+0x674
8f267c5c 817327b1 86159c58 00000001 86159c58 win32k!UserThreadCallout+0x4b
8f267c78 820745c0 86159c58 00000001 5d78ac39 win32k!W32pThreadCallout+0x3a
8f267ce4 8207383b c0000001 00000000 86159c58 nt!PspExitThread+0x488
8f267d04 82073d0c 86159c58 c0000001 00000001 nt!PspTerminateThreadByPointer+0x5b
8f267d34 8d06533f ffffffff c0000001 ffffffff nt!NtTerminateProcess+0x1e0
WARNING: Stack unwind information not available. Following frames may be wrong.
8f267d54 81f23b4a ffffffff c0000001 0014fc7c mfehidk+0x5733f
8f267d54 77915cf4 ffffffff c0000001 0014fc7c nt!KiSystemServicePostCall
0014fc7c 00000000 00000000 00000000 00000000 0x77915cf4

STACK_COMMAND: .trap 0xffffffff8f267b94 ; kb

THREAD_SHA1_HASH_MOD_FUNC: 63a1f43c675f809267d423233ed44202336ccdcd

THREAD_SHA1_HASH_MOD_FUNC_OFFSET: b1cb26121fabb099e2cc558ea7a21a1ecfa68655

THREAD_SHA1_HASH_MOD: 54d3b6811aefbe1577e87e5f7b205815f9b33101

FOLLOWUP_IP:
mfehidk+5733f
8d06533f 5f pop edi

FAULT_INSTR_CODE: e58b5b5f

SYMBOL_STACK_INDEX: 6

SYMBOL_NAME: mfehidk+5733f

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: mfehidk

IMAGE_NAME: mfehidk.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 5cc27657

FAILURE_BUCKET_ID: 0x8E_mfehidk+5733f

BUCKET_ID: 0x8E_mfehidk+5733f

PRIMARY_PROBLEM_CLASS: 0x8E_mfehidk+5733f

TARGET_TIME: 2019-11-14T04:31:38.000Z

OSBUILD: 6003

OSSERVICEPACK: 2000

SERVICEPACK_NUMBER: 0

OS_REVISION: 0

SUITE_MASK: 272

PRODUCT_TYPE: 3

OSPLATFORM_TYPE: x86

OSNAME: Windows 7

OSEDITION: Windows 7 Server (Service Pack 2) TerminalServer SingleUserTS

OS_LOCALE:

USER_LCID: 0

OSBUILD_TIMESTAMP: 2019-08-07 00:35:07

BUILDDATESTAMP_STR: 190806-2021

BUILDLAB_STR: vistasp2_ldr_escrow

BUILDOSVER_STR: 6.1.6003.20597.x86fre.vistasp2_ldr_escrow.190806-2021

ANALYSIS_SESSION_ELAPSED_TIME: 81c

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0x8e_mfehidk+5733f

FAILURE_ID_HASH: {0080b06e-405f-7877-0eb0-b7b67e6d37c3}

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

[AdithyanT]

Hi @Edgar1210,

Here is the list of known issues where we can find the driver reason behind few BSOD issues in the past. Blocking RDP may not be the driver. However, Please share with us the mentioned logs so that we can look into what may have lead to this derivation.

https://kc.mcafee.com/corporate/index?page=content&id=KB70393

As a simple check, have you tried unloading the Filter driver or rather uninstalling the product to see if it helps?

I would start with isolating what may have caused the issue by disabling the components one by one ( if the issue can be reproduced at will).

https://kc.mcafee.com/corporate/index?page=content&id=KB66254

I sincerely hope this helps!

[Edgar1210]

Hi @AdithyanT, I just got more information, it seems to be that mfehidk.sys is causing a "BSOD".

[mbuehler · Accepted solution]

Hi @Edgar1210 

Please open a service request with the information you've just provided and upload the memory dump from which this analysis was generated, as well as a MER from the system that blue screened.

We'll analyze the dump you've got here and either provide you with a recommendation to upgrade if this is already fixed, or send the dump up to our engineering team for further analysis.

Thank you,

[AdithyanT]

Hi @Edgar1210,

As my colleague mentioned above, Service Request would be the right way to go here. However, While creating one, It is important that we have a FULL MEMORY Dump from the machine.

Additionally, Is there a way you can reproduce the issue at will? Please keep us posted how this goes.