Пользовательский драйвер Windows замораживает систему со 100% процессором - PullRequest
0 голосов
/ 26 марта 2019

На терминальном сервере установлен драйвер уровня ядра. Он отлично работает в течение определенного периода времени на этом терминальном сервере. позже этот терминальный сервер сам попадает в заблокированное состояние, где noboday может подключиться к серверу через RDP и веб-консоль В моем случае, Процессор всегда зависает до 100% в зависшем состоянии, и мне приходилось перезагружаться только с помощью опции «выключить» виртуальной машины. После удаления этого драйвера сервер терминалов работает нормально или даже отвечает должным образом всегда. Даже если он использует процессор на 100% и работает медленно, но все еще отвечает на RDP и веб-консоль.

Этот сценарий довольно сложно воспроизвести. но все же мне удалось получить полный дамп памяти из этой машины в этом сценарии, а затем я проанализировал полный дамп памяти с помощью инструмента Microsoft WinDbg. Утилита WinDbg отображает имя неисправного драйвера и стек вызовов, как показано ниже

Имя модуля: MMTEProxy (установленный драйвер)

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

        NMI_HARDWARE_FAILURE (80)
        This is typically due to a hardware malfunction.  The hardware supplier should
        be called.
        Arguments:
        Arg1: 00000000004f4454
        Arg2: 0000000000000000
        Arg3: 0000000000000000
        Arg4: 0000000000000000

        Debugging Details:
        ------------------
        KEY_VALUES_STRING: 1

        PROCESSES_ANALYSIS: 1

        SERVICE_ANALYSIS: 1

        STACKHASH_ANALYSIS: 1

        TIMELINE_ANALYSIS: 1

        DUMP_CLASS: 1

        DUMP_QUALIFIER: 402

        BUILD_VERSION_STRING:  9600.17415.amd64fre.winblue_r4.141028-1500

        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:  04/05/2016

        BASEBOARD_MANUFACTURER:  Intel Corporation

        BASEBOARD_PRODUCT:  440BX Desktop Reference Platform

        BASEBOARD_VERSION:  None

        DUMP_TYPE:  0

        BUGCHECK_P1: 4f4454

        BUGCHECK_P2: 0

        BUGCHECK_P3: 0

        BUGCHECK_P4: 0

        CPU_COUNT: 2

        CPU_MHZ: bb8

        CPU_VENDOR:  GenuineIntel

        CPU_FAMILY: 6

        CPU_MODEL: 3e

        CPU_STEPPING: 4

        CPU_MICROCODE: 6,3e,4,0 (F,M,S,R)  SIG: 42C'00000000 (cache) 42C'00000000 (init)

        DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

        BUGCHECK_STR:  0x80

        PROCESS_NAME:  svchost.exe

        CURRENT_IRQL:  0

        ANALYSIS_SESSION_HOST:  INPN01LAP107

        ANALYSIS_SESSION_TIME:  03-26-2019 16:30:13.0120

        ANALYSIS_VERSION: 10.0.18317.1001 amd64fre

        LAST_CONTROL_TRANSFER:  from fffff8005ae205b2 to fffff8009a6601a7

        STACK_TEXT:  
        nt!KxWaitForLockOwnerShip+0x27
        MMTEProxy!SVSessionLutTranslatePort+0x2c2 [c:\users\dkelone\git\MMTE\MMTE\MMTEdriver\sessionlut.c @ 873] 
        MMTEProxy!PerformProxySocketRedirection+0xba7 [c:\users\dkelone\git\MMTE\MMTE\MMTEdriver\filteralebindredirect.c @ 247] 
        MMTEProxy!TriggerProxyByALERedirectInline+0x244 [c:\users\dkelone\git\MMTE\MMTE\MMTEdriver\filteralebindredirect.c @ 690] 
        MMTEProxy!DDProxyBindRedirectClassify+0x537 [c:\users\dkelone\git\MMTE\MMTE\MMTEdriver\filteralebindredirect.c @ 881] 

        THREAD_SHA1_HASH_MOD_FUNC:  03f7fb5fd041c46c9b4dff8f1685ccff753d3642

        THREAD_SHA1_HASH_MOD_FUNC_OFFSET:  7f4a5e830d38804e610244f134268d53640c97a0

        THREAD_SHA1_HASH_MOD:  2a8f232a3e3c38ad2a6b44b0d2253b97c2ac4b2a

        FOLLOWUP_IP: 
        MMTEProxy!SVSessionLutTranslatePort+2c2 [c:\users\dkelone\git\MMTE\MMTE\MMTEdriver\sessionlut.c @ 873]
        fffff800`5ae205b2 c644244000      mov     byte ptr [rsp+40h],0

        FAULT_INSTR_CODE:  402444c6

        FAULTING_SOURCE_LINE:  c:\users\dkelone\git\MMTE\MMTE\MMTEdriver\sessionlut.c

        FAULTING_SOURCE_FILE:  c:\users\dkelone\git\MMTE\MMTE\MMTEdriver\sessionlut.c

        FAULTING_SOURCE_LINE_NUMBER:  873

        FAULTING_SOURCE_CODE:  
        No source found for 'c:\users\dkelone\git\MMTE\MMTE\MMTEdriver\sessionlut.c'

        SYMBOL_STACK_INDEX:  1

        SYMBOL_NAME:  MMTEProxy!SVSessionLutTranslatePort+2c2

        FOLLOWUP_NAME:  MachineOwner

        MODULE_NAME: MMTEProxy

        IMAGE_NAME:  MMTEProxy.sys

        DEBUG_FLR_IMAGE_TIMESTAMP:  5a60d5f0

        STACK_COMMAND:  .thread ; .cxr ; kb

        BUCKET_ID_FUNC_OFFSET:  2c2

        FAILURE_BUCKET_ID:  0x80_MMTEProxy!SVSessionLutTranslatePort

        BUCKET_ID:  0x80_MMTEProxy!SVSessionLutTranslatePort

        PRIMARY_PROBLEM_CLASS:  0x80_MMTEProxy!SVSessionLutTranslatePort

        TARGET_TIME:  2019-02-26T11:15:36.000Z

        OSBUILD:  9600

        OSSERVICEPACK:  0

        SERVICEPACK_NUMBER: 0

        OS_REVISION: 0

        SUITE_MASK:  16

        PRODUCT_TYPE:  3

        OSPLATFORM_TYPE:  x64

        OSNAME:  Windows 8.1

        OSEDITION:  Windows 8.1 Server TerminalServer

        OS_LOCALE:  

        USER_LCID:  0

        OSBUILD_TIMESTAMP:  2014-10-29 06:08:48

        BUILDDATESTAMP_STR:  141028-1500

        BUILDLAB_STR:  winblue_r4

        BUILDOSVER_STR:  6.3.9600.17415.amd64fre.winblue_r4.141028-1500

        ANALYSIS_SESSION_ELAPSED_TIME:  685

        ANALYSIS_SOURCE:  KM

        FAILURE_ID_HASH_STRING:  km:0x80_MMTEProxy!svsessionluttranslateport

        FAILURE_ID_HASH:  {c64b7e97-0bf3-daf1-ad95-9f39cbf37a9a}

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

Так как я не являюсь экспертом в разработке драйверов уровня ядра, но я попытался найти драйвер в Google. Внутренне он использует следующую блокировку для выполнения любой операции над таблицей процессов или таблицей сеансов

        #Code snippet

    PLIST_ENTRY    processTableListHead = NULL;

    {
        ....

        KLOCK_QUEUE_HANDLE processTableLockHandle;
        KLOCK_QUEUE_HANDLE sessionTableLockHandle;

        PLIST_ENTRY tempNode = 0;
        ....
        ...

        KeAcquireInStackQueuedSpinLock(&gProcessTableLock,&processTableLockHandle);

        tempNode = processTableListHead;

        ...
        ...
        ..
        //Releases lock
        KeReleaseInStackQueuedSpinLock(&sessionTableLockHandle);
        KeReleaseInStackQueuedSpinLock(&processTableLockHandle);

    }

С помощью инструмента WinDbg, что я здесь наблюдал, в основном это происходит с ошибкой в ​​исходной строке, где она присваивает значение переменной и переменным, определенным до получения блокировки. Вы можете увидеть это в приведенном выше фрагменте кода драйвера. мой драйвер является фильтрованным драйвером WFP ALE. он проверяет трафик, работает в многопоточной среде, и мой драйвер выделяет / освобождает память в невыгружаемом пуле

И я также проверил, нет ли какого-либо тупикового условия или блокировки, удерживаемой в данный момент. до сих пор я не понимаю, что вызывает эту проблему. была ли его блокировка обработана должным образом на уровне кода или в какой-то конкретной ситуации.

Не могли бы вы помочь мне с указателем или направлением?

...