Не совсем понятный BSOD при ExFreePoolWithTag

Тема в разделе "WASM.NT.KERNEL", создана пользователем h0t, 13 янв 2012.

  1. Mika0x65

    Mika0x65 New Member

    Публикаций:
    0
    Регистрация:
    30 июл 2005
    Сообщения:
    1.384
    h0t
    Речь немного не об этом. Как целевой драйвер собирается возвращать информацию? SystemBuffer'а у него нет, MDL нет. А UserBuffer используется для компирования информации из SystemBuffer (при условии что стоит флаг IRP_BUFFERED_IO, а так же при условии, что обработка IRP продолжилась системой, т.е. completion routine вернула STATUS_SUCCESS). Может быть, конечно, целевой драйвер использует METHOD_NEITHER...
     
  2. h0t

    h0t Member

    Публикаций:
    0
    Регистрация:
    3 апр 2011
    Сообщения:
    735
    Он возвращает информацию в UserBuffer, так как если DO_BUFFERED_IO и DO_DIRECT_IO нет, то информация берется именно от сюда. Если не верите можете проверить сами).
     
  3. Mika0x65

    Mika0x65 New Member

    Публикаций:
    0
    Регистрация:
    30 июл 2005
    Сообщения:
    1.384
    h0t
    А, у устройства этих флагов нет. Видимо, какая-то специфика фильтров...
     
  4. h0t

    h0t Member

    Публикаций:
    0
    Регистрация:
    3 апр 2011
    Сообщения:
    735
    x64, shchetinin

    Спасибо.

    Заюзал IoBuildSynchronousFsdRequest, вроде все стало нормально.

    P.S. Осталось сравнить irp пакеты и прочее и понять чего же не так...
     
  5. Mika0x65

    Mika0x65 New Member

    Публикаций:
    0
    Регистрация:
    30 июл 2005
    Сообщения:
    1.384
    h0t
    Код в #1 не добавляет IRP в список IRP потока. Кстати, код ф-ий IoBuildSynchronousFsdRequest и IoBuildASynchronousFsdRequest есть в WRK, там я его и посмотрел :).
     
  6. h0t

    h0t Member

    Публикаций:
    0
    Регистрация:
    3 апр 2011
    Сообщения:
    735
    Спасибо, гляну.
     
  7. z0mailbox

    z0mailbox z0

    Публикаций:
    0
    Регистрация:
    3 фев 2005
    Сообщения:
    635
    Адрес:
    Russia СПБ
    у мну была подобная фигня как раз два раза флтмгр и два раза мой фильтр = переполнение ядерного стека
    дофига локалов было - перенес в пул и переполнение прошло
    обычно оно выглядит как дабл фолт но вроде были и типа такого акробатические этюды
    оно системозависимо - например на 2003 нет а на 2008 есть - на том же дрове
     
  8. Mika0x65

    Mika0x65 New Member

    Публикаций:
    0
    Регистрация:
    30 июл 2005
    Сообщения:
    1.384
    Раз уж речь зашла про эти ф-ии, спрошу кое-что по ним. h0t'у, вероятно, эта информация тоже пригодится, так что новую тему создавать не буду. После чтения беседы на OSR, у меня появилось впечатление, что все эти ф-ии для построения IRP либо лучше не использовать, либо давать им завершаться в IoCompleteRequest (т.е. не возвращать STATUS_MORE_PROCESSING_REQUIRED). Речь идет о сихронных ф-ия, конечно же. Проверять я так и не проверил, но может кто-нибудь поделится опытом их использования?
     
  9. Mika0x65

    Mika0x65 New Member

    Публикаций:
    0
    Регистрация:
    30 июл 2005
    Сообщения:
    1.384
  10. h0t

    h0t Member

    Публикаций:
    0
    Регистрация:
    3 апр 2011
    Сообщения:
    735
    Читал когда-то эту ветку, да и вообще часто возникает необходимость.
    У Они на эту тему по-моему целый раздел. В итоге после долгих проб и ошибок идельного в общем решения я так и не нашел. А в конкретном млучае, мне кажется вполне можно использовать. STATUS_MORE_PROCESSING_REQUIRED народ юзает как наиболее простой вариант.
     
  11. Mika0x65

    Mika0x65 New Member

    Публикаций:
    0
    Регистрация:
    30 июл 2005
    Сообщения:
    1.384
    h0t
    Его в той ветке за этот раздел и пинают :). Идеальное решение должно быть -- работает же это все как-то. Другой вопрос, что без WRK понять иногда бывает сложно. Ну и помнить это все еще надо...
    Смотря какой код. Построить IRP с помощью ф-ии создания синхронного IRP и вернуть STATUS_MORE_PROCESSING_REQUIRED в completion routine таки нельзя, насколько я понимаю. Ф-ии создания синхронного IRP добавляют IRP в список к вызывающему потоку. Документированных способов вытащить его из списка IRP потока нет. Получается, что если поток помрет после того как была вызвана IoFreeIrp, будет попытка завершить IRP второй раз, что, естественно карается. А IopCompletionRoutine вынимает IRP из списка IRP потока, так что все заканчивается благополучно.