Всем доброго!
В драйвер фильтре мне приходиться работать с "моими файлами", соответсвенно нежелательно получать весь набор IRP пакетов по текщим файлам, для этой цели использую Shadow Device, и все бы ничего, но есть вопрос.
После открытия файлов в диспечир приходит IRP_MJ_CREATE для Shadow Device, а вот все прочии пакеты уже приходят на стандартный девайс, это нормальное явление или я допустил ошибку?
Почему все прочии IRP не прирходят на Shadow Device?

Заранее спасибо!

Здравствуйте, Lucky_Devil, Вы писали:

L_D>Всем доброго!
L_D>В драйвер фильтре мне приходиться работать с "моими файлами", соответсвенно нежелательно получать весь набор IRP пакетов по текщим файлам, для этой цели использую Shadow Device, и все бы ничего, но есть вопрос.
L_D>После открытия файлов в диспечир приходит IRP_MJ_CREATE для Shadow Device, а вот все прочии пакеты уже приходят на стандартный девайс, это нормальное явление или я допустил ошибку?
L_D>Почему все прочии IRP не прирходят на Shadow Device?

L_D>Заранее спасибо!

Нормальное поведение, "Shadow Device" как раз и задумывался для того что-бы во время IRP_MJ_CREATE вы могли открыть файл, и не получить дедлок.

Если у вас такая странная реализация что хочется не видеть своих запросов в других IRP_MJ_XXX, то запоминайте файловые обьекты и фильтруйте по ним (но это плохая затея в принципе.)

Здравствуйте, Злость, Вы писали:


З>Нормальное поведение, "Shadow Device" как раз и задумывался для того что-бы во время IRP_MJ_CREATE вы могли открыть файл, и не получить дедлок.

З>Если у вас такая странная реализация что хочется не видеть своих запросов в других IRP_MJ_XXX, то запоминайте файловые обьекты и фильтруйте по ним (но это плохая затея в принципе.)

Ну знать это нормальное явление, просто возникла мысль, что я что-то сделал не так, потому чтополучил вот такое сообщение "NTFS: Stack space low. Posting create request."
получаю я его при попытке переименовки "своих файлов", когда приходит IRP_MJ_SET_INFORMATION.
На OSR по данной теме говорилось, что проблема может быть в нехватке памяти в стеке при создании имен файлов или в неверной адресации в низ по стеку устройств.
Как бороться с этим?
Решение нужно для w2k, для XP вроде как есть http://www.osronline.com/article.cfm?article=258

К примеру, если я создам подзадачу когда придет IRP_MJ_SET_INFORMATION, и в ней уже буду делать переименование "моих файлов", удасться ли мне избежать подобного рода ситуаций "NTFS: Stack space low. Posting create request."

Здравствуйте, Lucky_Devil, Вы писали:

L_D>Ну знать это нормальное явление, просто возникла мысль, что я что-то сделал не так, потому чтополучил вот такое сообщение "NTFS: Stack space low. Posting create request."
L_D>получаю я его при попытке переименовки "своих файлов", когда приходит IRP_MJ_SET_INFORMATION.
L_D>На OSR по данной теме говорилось, что проблема может быть в нехватке памяти в стеке при создании имен файлов или в неверной адресации в низ по стеку устройств.
L_D>Как бороться с этим?

Если вы уверенны что это переполнение стека ядра (проверряется с помощью отладчика), то как минимум это минимизировать свои локальные переменные (тоесть убрать у себя определение вида WCHAR FileName[MAX_PATH] и все выделять из
(non)PagedPool.

L_D>Решение нужно для w2k, для XP вроде как есть http://www.osronline.com/article.cfm?article=258

А это решение как обойтись без теневого устройства и к переполнению стека оно не относится.

Здравствуйте, Lucky_Devil, Вы писали:

L_D>К примеру, если я создам подзадачу когда придет IRP_MJ_SET_INFORMATION, и в ней уже буду делать переименование "моих файлов", удасться ли мне избежать подобного рода ситуаций "NTFS: Stack space low. Posting create request."

Если я вас правильно понял — то вы говорите про отдельный поток. То мой ответ таков:
1. Если память по стек забиваете практически всю вы — то не поможет(при изменении функционала вы добавите ту дельту которя вызовет опять переполение стека).
2. Если ваши локальные переменные являются той дельтой которая рушит стек — то возможно поможет. Но тоже не в 100% случаях, но зато можно сказать что, это не ваша вина!

Здравствуйте, Злость, Вы писали:


З>Если вы уверенны что это переполнение стека ядра (проверряется с помощью отладчика), то как минимум это минимизировать свои локальные переменные (тоесть убрать у себя определение вида WCHAR FileName[MAX_PATH] и все выделять из
З>(non)PagedPool.

Да так и есть, использую именно WCHAR FileName[MAX_PATH], выделение из (non)PagedPool действительно может помочь?
просто, я стал замечать, что количество отказов в веделение не страничной памяти достаточно высока, блакого можно заново заставить системы сгенерировать запрос и молиться что на этот раз памяти будет более чем достаточно.
Еще вопрос, если мне не удасться зполучить память под мою переменную, с каким статусом мне завершить IRP_MJ_SET_INFORMATION пакет, с STATUS_INSUFFICIENT_RESOURCES будет правильно?

Здравствуйте, Lucky_Devil, Вы писали:
[skip]

З>>Если вы уверенны что это переполнение стека ядра (проверряется с помощью отладчика), то как минимум это минимизировать свои локальные переменные (тоесть убрать у себя определение вида WCHAR FileName[MAX_PATH] и все выделять из
З>>(non)PagedPool.

L_D>Да так и есть, использую именно WCHAR FileName[MAX_PATH], выделение из (non)PagedPool действительно может помочь?
L_D>просто, я стал замечать, что количество отказов в веделение не страничной памяти достаточно высока, блакого можно заново заставить системы сгенерировать запрос и молиться что на этот раз памяти будет более чем достаточно.

Отказ на выделение памяти из странично или нестраничног пула (это скорее всего имеем большие утечки).
Мало можно найти софта которые должен 'очень старатся' продолжать жить на такой системе.

L_D>Еще вопрос, если мне не удасться зполучить память под мою переменную, с каким статусом мне завершить IRP_MJ_SET_INFORMATION пакет, с STATUS_INSUFFICIENT_RESOURCES будет правильно?

Как минимум это завист от FileInformationClass. Точно ответа я не знаю (что-бы не брать на себя ответственность Но в принципе вернуть можно любую ошибку (но вот как поведет себя система — только экперимент поможет вам)

Здравствуйте, Злость, Вы писали:

З>Отказ на выделение памяти из странично или нестраничног пула (это скорее всего имеем большие утечки).
З>Мало можно найти софта которые должен 'очень старатся' продолжать жить на такой системе.

Утечка действительно может существовать, но думаю если бы это было белее чем дозволено, то Verifier давно бы уже дал мне знать. Драйвер тестируеться исключительно только под ним.
Немного о ресурсах испытуемой машины:
P-IV 3 Ghz
RAM 128 Mb
W2K SP-4(Advanced Server)

Здравствуйте, Lucky_Devil, Вы писали:

L_D>Здравствуйте, Злость, Вы писали:

З>>Отказ на выделение памяти из странично или нестраничног пула (это скорее всего имеем большие утечки).
З>>Мало можно найти софта которые должен 'очень старатся' продолжать жить на такой системе.

L_D>Утечка действительно может существовать, но думаю если бы это было белее чем дозволено, то Verifier давно бы уже дал мне знать. Драйвер тестируеться исключительно только под ним.
L_D>Немного о ресурсах испытуемой машины:
L_D>P-IV 3 Ghz
L_D>RAM 128 Mb
L_D>W2K SP-4(Advanced Server)

Тогда
1. Тыпаться выделять какое-то время().
2. Использовать свои распределнные участки памяти.

Но верифер вам не скажет что вы распределили кучу памяти и хватит. Используйте PoolTag.

Здравствуйте, Злость, Вы писали:

З>Тогда
З>1. Тыпаться выделять какое-то время().
З>2. Использовать свои распределнные участки памяти.

З>Но верифер вам не скажет что вы распределили кучу памяти и хватит. Используйте PoolTag.

Вообщем пошел сразу же 2 путями, во-первых отказался от WCHAR deviceNameBuffer[MAX_PATH_LENGTH], это дело мне и раньше не нравилось, но все руки не доходили, теперь только динамическое выделение, остается только вопрос как будет себя вести система, если не хватит ресурса под переменную, знаю что при IRP_MJ_READ\WRITE проблем нет, с STATUS_INSUFFICIENT_RESOURCES.
Ну и заодно все же создал воркайтам, все же с ним как-то увереней я себя чувствую, после всех переделок сообщений подобного рода "NTFS: Stack space low. Posting create request." не наблюдаю. Хотелось бы надеяться, что на одну проблему стало меньше.

Ну и как всегда один вопрос в догонку: Данный метод работы со "своими файлами" через Shadow Device, уместин ли он в XP, т.е. не возникнут ли проблемы с этим методом? или однозначно придется работать только с IoCreateFileSpecifyDeviceObjectHint?

Здравствуйте, Lucky_Devil, Вы писали:

[skip]

L_D>Ну и как всегда один вопрос в догонку: Данный метод работы со "своими файлами" через Shadow Device, уместин ли он в XP, т.е. не возникнут ли проблемы с этим методом? или однозначно придется работать только с IoCreateFileSpecifyDeviceObjectHint?

Ответ — IoCreateFileSpecifyDeviceObjectHint появился как раз что-бы обходить проблему которые раньше решали таким вот странным способом как создание "теневого" устройства.

Всем доброго!
Собственно решил продолжить начатую тему, потому как я не знаю как быть с возникшей проблемой.
Речь идет о следующем:
При получении IRP_MJ_CREATE, я пытаюсь выделить(NonPagedPool) ресурс под собственную переменную, так вот иногда эта попытка завершается неудачей, я пытался завершать этот запрос таким образом
Irp->IoStatus.Status = STATUS_INSUFFICIENT_RESOURCES;
Irp->IoStatus.Information = 0;
IoCompleteRequest (Irp, IO_NO_INCREMENT);
return STATUS_INSUFFICIENT_RESOURCES;
но желаемого результата такое завершение не дает, а именно я надеялся, что в такой комбинации система вновь сформирует IRP_MJ_CREATE, но как выясняется, этого не происходит, как решить эту проблему?

Здравствуйте, Lucky_Devil, Вы писали:

L_D>но желаемого результата такое завершение не дает, а именно я надеялся, что в такой комбинации система вновь сформирует IRP_MJ_CREATE, но как выясняется, этого не происходит, как решить эту проблему?
Вы уже сделали практически то что должны были — не ждите от других чудес

давайте подумаем логически, что можно сделать если абсолютно необходимых ресурсов в системе физически нет?

вариантов несколько:
— выделить заранее\попросить ресурсы из спецфонда (но там тоже всему есть предел — это надо понимать)
— позволить системе расстрел себя, предполагая что ресурсы всегда для Вас найдут — весьма рискованно, не наш путь есс-но
— застрелиться самому, т.е. аккуратно положить систему с багчеком к примеру
— предоставить выбрать вариант кому-то еще, вернув статус мол мы умываем руки (что Вы и делаете, ведь нет гарантий что такое поведение будет спасением) в надежде что сверху все звенья цепочки к этому готовы

IRP_MJ_CREATE же формируется повторно
— при репарсинге
— когда кто-то сверху специально имеет такое поведение, что не есть правда в случае IO manager

посему вынужден сообщить, что чудес не бывает. (С)
если только Вы их не создаете своим тяжелым трудом (С) мой

PS убедился на примере душераздирающего зрелища Щвейцария — Украина. Ох и прет же братьям-славянам. Но дальше — ce finita! C такой игрой на мундиале даже находиться все же стыдно. Впрочем Италия скоро объяснит что такое finita! прогнозирую победу в два мячика. минимум.

PPS хорошо, есть изощренный вариант борьбы с нехваткой ресурсов, скажем так профессиональный вариант приведенного выше посл варианта — позволит лишь гарантированно не упасть в Вашем коде, но не избавит от падения в общем виде. Будет интересно — могу поделиться

Здравствуйте, Valery A. Boronin, Вы писали:

VAB>PPS хорошо, есть изощренный вариант борьбы с нехваткой ресурсов, скажем так профессиональный вариант приведенного выше посл варианта — позволит лишь гарантированно не упасть в Вашем коде, но не избавит от падения в общем виде. Будет интересно — могу поделиться

Очень интересно

Здравствуйте, Valery A. Boronin, Вы писали:


VAB>PS убедился на примере душераздирающего зрелища Щвейцария — Украина. Ох и прет же братьям-славянам. Но дальше — ce finita! C такой игрой на мундиале даже находиться все же стыдно. Впрочем Италия скоро объяснит что такое finita! прогнозирую победу в два мячика. минимум.

Игра действительно, оставляет желать лучшего, фортуна благосклонна Украине, но надолго ли!?

VAB>PPS хорошо, есть изощренный вариант борьбы с нехваткой ресурсов, скажем так профессиональный вариант приведенного выше посл варианта — позволит лишь гарантированно не упасть в Вашем коде, но не избавит от падения в общем виде. Будет интересно — могу поделиться

Безумно интересно, было бы интересно узнать как решается проблема подобного рода.

Здравствуйте, Lucky_Devil, Вы писали:

[skip]

VAB>>PPS хорошо, есть изощренный вариант борьбы с нехваткой ресурсов, скажем так профессиональный вариант приведенного выше посл варианта — позволит лишь гарантированно не упасть в Вашем коде, но не избавит от падения в общем виде. Будет интересно — могу поделиться

L_D>Безумно интересно, было бы интересно узнать как решается проблема подобного рода.

Заготовкой зарание блока прозапас.

Здравствуйте, Злость, Вы писали:

VAB>>>PPS хорошо, есть изощренный вариант борьбы с нехваткой ресурсов, скажем так профессиональный вариант приведенного выше посл варианта — позволит лишь гарантированно не упасть в Вашем коде, но не избавит от падения в общем виде. Будет интересно — могу поделиться

L_D>>Безумно интересно, было бы интересно узнать как решается проблема подобного рода.

З>Заготовкой зарание блока прозапас.
это было бы слишком просто. конечно это часть решения, остальное расскажу чуть позже — флажок на тему поставил.

Здравствуйте, Valery A. Boronin, Вы писали:

VAB>это было бы слишком просто. конечно это часть решения, остальное расскажу чуть позже — флажок на тему поставил.

Ну совсем затомил, я тут уже весь извелся .

Попутно возникла проблема все про тоже, если до этого выделение ресурсов в MJ_CREATE приводило к неудаче, я уже практически смерился с этим, но я никак не ожидал встретить подобную проблему в MJ_WRITE, почему то у меня было мнение, что при завершение запроса со статусом STATUS_INSUFFICIENT_RESOURCES, система попытается повторно выполнить
запрос, но этогоне происходит, в чем я мог ошибиться?

Попытка веделения ресурса, осуществляеться в диспечере(MJ_WRITE), если она происходит не удачно, завершаю запрос со статусом STATUS_INSUFFICIENT_RESOURCES в диспечире, не в роутин функции, это правильно?

L_D>Попутно возникла проблема все про тоже, если до этого выделение ресурсов в MJ_CREATE приводило к неудаче, я уже практически смерился с этим, но я никак не ожидал встретить подобную проблему в MJ_WRITE, почему то у меня было мнение, что при завершение запроса со статусом STATUS_INSUFFICIENT_RESOURCES, система попытается повторно выполнить
L_D>запрос, но этогоне происходит, в чем я мог ошибиться?
я так до сих пор и не понял — откуда у Вас эта уверенность что в случае ошибок кто-то сверху будет настойчиво повторять запросы? и доколе? 2-3-5 раз или вечный цикл угодно?

еще раз повторю — зависит от поведения того кто выше, и IO Manager не имеет например логики которую можно встретить в storage стеке — там действительно в зависимости от разных режимов SCSI, флажков-настроек class driver (classpnp) пытается повторять сбойные операции или применять логику скажем разбиения большого пакета на мелкие в случае если в системе совсем нет ресурсов — но это же не вся система!

L_D>Попытка веделения ресурса, осуществляеться в диспечере(MJ_WRITE), если она происходит не удачно, завершаю запрос со статусом STATUS_INSUFFICIENT_RESOURCES в диспечире, не в роутин функции, это правильно?
что есть "диспечир", что есть "роутин ф-я"?

routine — подпрограмма (Eng.)

запрос можно завершить с кодом ошибки и в dispatch handler и в completion routine