У меня, время от времени, при использовании даной команды бывает крах системы. Поэтому вопрос адресуется людям, которые знают что такое PAGEIN, swap, WinDbgExtensionDllInit, BSOD ;)
В книге Р.А. АЙРАПЕТЯНА сказано следующее: "команду PAGEIN следует использовать с мерами предосторожности, так как если текущий поток не находится в контексте, которому доступна область подгружаемой памяти, то даное действие может вызвать крах системы". Вот именно у меня это "МОЖЕТ" занимает где то 40%. Если всё я правильно понял, то поток исполняющийся на IRQL > IRQL_PASSIVE_LEVEL (APC_LEVEL) и является причиной сбоя. Наконец вопрос: насколько реально создание расширения отладчика на уровне ядра с приблизительно таким кодом:

KIRQL new, oldIrql;
KeLowerIrql(old);
...PAGEIN
KeRaiseIrql(new, &oldIrql);

Я ещё никогда не писал "расширения", поэтому перед началом взрывных робот хочу проконсультироватся.

| Сообщение посчитали полезным:

Как решение проблемы - докупить памяти.
чем больше ОЗУ, тем меньше шансов встретить выгруженную страницу.

| Сообщение посчитали полезным:

AG
Всё это прекрасно, но мне нужно подкачать страницу, которая в текущий момент сброшена драйвером на диск.

| Сообщение посчитали полезным:

PAGEIN на самом деле выполняет команду mov eax, [addr]
Если IRQL >= DISPATCH_LEVEL, то обращаться к подкачиваемой памяти нельзя и поэтому происходит бсод.
Понизить IRQL возможно путем модификации поля Irql структуры ETHREAD связаной с текущим потоком, но как показывает практика, ни к чему хорошему это не приведет.
С помощью KeLowerIrql понизить irql нельзя, так как ядро просто не даст это сделать.
Единственный нормальный вариант - установить Kernel Mode APC какому-нибудь потоку, в котором он обратиться к этой памяти. Если нужно синхронизировать поток на DISPATCH_LEVEL, то нельзя использовать функции ожидания. Единственно возможный вариант - KeStallExecutionProcessor

-----
Скажем дружно - нафиг нужно.

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным:

Ms-Rem пишет:
Понизить IRQL возможно путем модификации поля Irql структуры ETHREAD связаной с текущим потоком
Вот это уже идея. Это легко и в тоже время не требует написания "расширения" (достаточно двух макросов). Насчёт проблемы, в таком случае, с понижением Irql - это можно пережить, если не перестаратся с взаимоблокировками отлажываемых потоков.
Как я раньше не сообразил... Теперь вперёд и с песней...
Благодарю всех за ответы.

| Сообщение посчитали полезным:

Barakuda пишет:
Вот это уже идея. Это легко и в тоже время не требует написания "расширения" (достаточно двух макросов). Насчёт проблемы, в таком случае, с понижением Irql - это можно пережить, если не перестаратся с взаимоблокировками отлажываемых потоков.

Лучше так не делай. Оно работать будет, но после этого система начинает падать в случайный момент времени. С чем это связвно я не разбирался, а просто сделал второй поток для подкачки.

-----
Скажем дружно - нафиг нужно.

| Сообщение посчитали полезным:

Ms-Rem пишет:
Лучше так не делай. Оно работать будет, но после этого система начинает падать в случайный момент времени.

Ты мне как серпом по ...
Ладно, тогда пойдём долгим путём через APC, и временного freez-a для больно умных потоков.

| Сообщение посчитали полезным: