Способы заморозить окна из пользовательского пространства

Question

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

Например, у меня есть диспетчер задач и несколько команд, открытых в момент остановки. Диспетчер задач работает хорошо, отображает использование процессора / памяти, список всех процессов и т. Д. Но если я попытаюсь убить процесс, он зависнет. Если бы я попытался открыть File -> New Task, он завис бы. В cmd, если я попытаюсь открыть приложение Windows, команда будет выполнена, и в диспетчере задач появится новый процесс, но приложение не запустится. Даже запуск приложения командной строки зависнет.

Данное программное обеспечение представляет собой набор из 12 различных приложений-служб, которые взаимодействуют друг с другом с помощью WCF. Большая часть написана на C #, есть немного Fortran, C ++. Все это работает в пространстве пользователя, у нас ничего не выполняется в пространстве ядра.

Итак, мой вопрос: кто-нибудь видел такое или подобное поведение? Каковы были причины? Теоретически, ничего из того, что делает пользовательское приложение, не должно заморозить всю ОС? Любые советы по отладке этой ситуации также будут полезны. Спасибо за ваше время.

Обновление 1:

Мы попытались написать небольшое приложение, которое постоянно записывает / читает (со случайным поиском и открытием / закрытием файла) с диска и запускается до зависания системы. Приложение продолжало успешно писать / читать, открывая и закрывая файлы после зависания. Использование памяти такое же, как и при обычном использовании, от 4 до 5 ГБ система имеет 6 ГБ.

Мы также сделали дамп памяти, проблема в том, что мы не смогли понять, что происходит. Дамп, конечно, показывает, что окна зависли в драйвере клавиатуры, но, кроме того, мы не могли ничего понять. Было бы гораздо полезнее, если бы мы могли сделать дамп памяти пространства пользователя. Хорошо, это предложение заставило меня немного погуглить, похоже, есть полная опция дампа памяти, мы еще немного разберемся в этом и узнаем о прогрессе.

Наш текущий подозреваемый - брандмауэр NOD32, когда он выключен, все работает нормально. Нам все еще нужно это подтвердить и выяснить, что в нашем коде вызывает такое поведение.

Спасибо всем за помощь.

Обновление 2:

Хорошо, мне удалось создать полный дамп памяти. Это было не так просто, как я надеялся, вот некоторые полезные ресурсы, может быть, они когда-нибудь кому-нибудь помогут ..:

http://www.osronline.com/article.cfm?article=545

http://blogs.msdn.com/b/ntdebugging/archive/2010/04/02/how-to-use-the-dedicateddumpfile-registry-value-to-overcome-space-limitations-on-the-system-drive-when-capturing-a-system-memory-dump.aspx

Как только система зависла, я запустил один cmd.exe и инициировал команду копирования, cmd завис, и вот его трассировка стека:

    fffff880`087571d0 fffff800`02cc2992 nt!KiSwapContext+0x7a
    fffff880`08757310 fffff800`02cc4d0f nt!KiCommitThreadWait+0x1d2
    fffff880`087573a0 fffff800`02cd9d1f nt!KeWaitForSingleObject+0x19f
    fffff880`08757440 fffff800`02fc06d6 nt!AlpcpSignalAndWait+0x8f
    fffff880`087574f0 fffff800`02fbe660 nt!AlpcpReceiveSynchronousReply+0x46
    fffff880`08757550 fffff800`02fcd13d nt!AlpcpProcessSynchronousRequest+0x33d
    fffff880`08757670 fffff800`030ade59 nt!LpcpRequestWaitReplyPort+0x9c
    fffff880`087576d0 fffff880`05ad1344 nt!LpcRequestWaitReplyPort+0x19
    fffff880`08757710 fffff880`05ad430f eamon+0x5344
    fffff880`087578d0 fffff880`05ad25bb eamon+0x830f
    fffff880`08757970 fffff800`02fd075f eamon+0x65bb
    fffff880`087579f0 fffff800`02fb6624 nt!IopCloseFile+0x11f
    fffff880`08757a80 fffff800`02fd0251 nt!ObpDecrementHandleCount+0xb4
    fffff880`08757b00 fffff800`02fd0164 nt!ObpCloseHandleTableEntry+0xb1
    fffff880`08757b90 fffff800`02cba953 nt!ObpCloseHandle+0x94
    fffff880`08757be0 00000000`77bff7aa nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff880`08757be0)
    00000000`002fd848 00000000`00000000 ntdll!ZwClose+0xa

Обновление 3:

После тщательного тестирования мы пришли к выводу, что проблема связана с антивирусом ESET NOD32. Спасибо всем за помощь и предоставленную информацию.

Answer 1

Поскольку зависание вызвано незавершенным вводом / выводом, проблема, скорее всего, связана с драйвером

Я бы начал с ! Анализ в собранном вами дампе памяти ядра. Во многих случаях это может сразу определить проблему или дать подсказку, где искать.

Если! Analyse не сообщает ничего полезного, вы можете попытаться получить больше информации о том, какой драйвер задействован в замораживании, изучив IRP остановленного потока.

1. Найти список IRP в заблокированных темах. Список ожидающих IRP появляется в выводе !thread.
2. Вывод IRP с помощью команды !irp.

IRP может выглядеть примерно так:

kd> !irp 8420d320
Irp is active with 4 stacks 2 is current (= 0x8420d3b4)
 No Mdl: No System Buffer: Thread 8426b420:  Irp stack trace.  
     cmd  flg cl Device   File     Completion-Context
 [  0, 0]   0  0 00000000 00000000 00000000-00000000    

            Args: 00000000 00000000 00000000 00000000
>[  0, 0]   0 e0 84d1e878 84275bd0 86be23be-83bb1908 Success Error Cancel 
           \FileSystem\mrxsmb   mup!MupiUncProviderCompletion
            Args: 88795aac 01220044 00050000 00000000
 [  0, 0]   0 e0 84723700 84275bd0 863bf4de-84bc9228 Success Error Cancel 
           \FileSystem\Mup  fltmgr!FltpSynchronizedOperationCompletion
            Args: 88795aac 01220044 00050000 00000000
 [  0, 0]   0  0 847231f0 84275bd0 00000000-00000000    
           \FileSystem\FltMgr
            Args: 88795aac 01220044 00050000 00000000

Активный стек в IPR помечен >. В приведенном выше примере он ожидает устройства \ FileSystem \ mrxsmb.

Чтобы упростить расследование, уделите время настройке отладчика ядра для машины. Это необязательно, но это проще, чем обработка дампов памяти.

Answer 2

Не уверен в возможных причинах, но, на мой взгляд, лучший способ продолжить - это создать полный дамп памяти во время остановки и найти там подсказки с помощью WinDbg. См. здесь , как создать BSOD с помощью клавиатуры.

Answer 3

Из дампа стека драйвер "eamon.sys", похоже, находится в середине битвы.Как вы сказали, этот драйвер связан с антивирусом ESET NOD32.

Если вы добавите к этому тот факт, что без него все работает нормально, вам следует прекратить свои исследования здесь.Пакеты антивирусного программного обеспечения по определению устанавливаются как драйверы, поэтому они могут эффективно выполнять свою работу.Недостатком этого является то, что когда у них возникают проблемы, это означает, что они могут легко перегружать машину или вызывать BSOD.

Немного погуглив, есть и другие подобные отчеты об этом конкретном программном обеспечении (http://www.wilderssecurity.com/archive/index.php/t-259245.html).

Вам следует связаться с продавцом и узнать, нормально ли это, или у него есть обновление или способ исправить это.

Answer 4

У вас загружены символы Windows (хорошо), и вы обнаружили, что проблема, скорее всего, связана с драйвером eamon.sys.Небольшой поиск в Google привел меня к этому , который выглядит как антивирусный сканер.Если бы я был вами, я бы сообщил об этом дампе ребятам из антивирусного ПО и спросил, не испортили ли они.

Вирусные сканеры являются одним из основных источников таких сбоев системы.Они настолько глубоко взаимодействуют с ОС, что время от времени могут происходить сбои в работе определенных аппаратных конфигураций с различными временными интервалами, когда обнаруживаются незначительные ошибки.

Answer 5

Похоже на ожидание запросов дискового ввода-вывода, которые не выполняются своевременно.

Либо у вас есть ошибка ввода-вывода (отключение шины, тому подобное) или слишком длинная очередьДисковые запросы вызывают много поиска.Использование файла подкачки может вызвать это.

Что показывает диспетчер задач для использования памяти?

Answer 6

Я бы проверил следующие вещи:

1. Когда заморозить, как насчет использования процессора? Это полностью занято каким-либо процессом?
2. На какой ОС вы столкнулись с этой проблемой? Это Vista или Win7? Есть ли у ваших служб соответствующие права для выполнения определенной операции?
3. Поскольку вы упомянули брандмауэр, возможно, имеет смысл включить журнал для брандмауэра и посмотреть, произошло ли что-нибудь, когда в журнале произошло замораживание. Брандмауэр пытается что-то заблокировать? А ваши службы постоянно пытаются настроить / загрузить это?
4. Возможно ли включение регистрации в ваши сервисы и сужение дела? Вероятно, он показывает, когда это приводит к зависанию системы, и тогда вы можете заметить, что это вызвало конкретная операция.

Надеюсь, это поможет.