UNICODE_STRING и IRQL

Тема в разделе "WASM.NT.KERNEL", создана пользователем ntdrivers, 4 янв 2011.

Страница 2 из 2
  1. Deyton

    Deyton Member

    Публикаций:
    0
    Регистрация:
    7 мар 2007
    Сообщения:
    94
    Для применения конкретных функций на конкретных ОС и их билдах можно. А как для меня, - в топку эти NLS таблицы, в подавляющем большинстве случаев у нас можно обойтись более простой реализацией, как это сделано в ReactOS. В общем случае, конечно, лучше придерживаться официальной документации. Но, поверьте мне, без реверса, на одном MSDN, далеко не уедешь, подобные вопросы будут возникать бесконечно.
     
    Deyton, 8 янв 2011
    #21
  2. TermoSINteZ

    TermoSINteZ Синоби даоса Команда форума

    Публикаций:
    2
    Регистрация:
    11 июн 2004
    Сообщения:
    3.552
    Адрес:
    Russia
    Deyton
    Верю, и не спорю. )
     
    TermoSINteZ, 8 янв 2011
    #22
  3. halic

    halic New Member

    Публикаций:
    0
    Регистрация:
    8 дек 2010
    Сообщения:
    1
    В SP2(free) не падает, а в SP3(free) даже DbgPrint с UNICODE_STRING падает; при APC_LEVEL, конечно. Помоему, в checked версии SP2 тоже падает.
    Еще вариант, помимо второго потока: запускать worker'а при каждом уведомлении; он всегда на PASSIVE_LEVEL, но в контексте System.
     
    halic, 9 янв 2011
    #23
  4. Ladr

    Ladr New Member

    Публикаций:
    0
    Регистрация:
    28 мар 2009
    Сообщения:
    17
    Сам только что наткнулся на подобную проблему. Есть подозрение что RtlCompareUnicodeString все же можно вызывать на APC_LEVEL. На этом IRQL можно работать с pageable памятью Чисто ошибка документации.
    Решение: писать свою ф-цию сравнения на основе RtlUpcaseUnicodeChar, которую можно вызывать на APC_LEVEL. Здесь не надо буфер освобождать.
     
    Ladr, 28 мар 2011
    #24
Страница 2 из 2