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

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

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

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

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

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

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

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

Нашим подозреваемым в настоящее время является брандмауэр 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. Спасибо всем за вашу помощь и предоставленную информацию.