Ну ты блин спросил.
Из вопроса сразу становится ясно, что стандартный механизм тебе не подходит, так как он создает поддерживаемую файлом секцию (backed by the file).
Но можно выкрутится так- надо заблокировать страницы с кодом и данными в памяти, запретив убирать их из рабочего набора.
Тут два варианта- первый, если тебе надо загрузить dll из режима ядра, и второй, если dll уже загружена в юзерском процессе, но тебе надо заблокировать страницы в памяти.
В первом случае я бы попытался сделать так. Создать свой драйвер, к которому прилинковать эту dll, это вызовет загрузку этой dll при загрузке драйвера. По другому загрузить dll в режиме ядра будет трудно- этот процесс недокументирован, нет аналога LoadLibrary. В этом деле тебе поможет статья
http://www.wd-3.com/archive/KernelDlls.htm . Далее тебе надо или получить виртуальные адреса по которому загружена dll и заблокировать их при помощи MmProbeAndLockPages, или вызвать MmLockPagableCodeSection с любым адресом, принадлежащем загруженной dll- это может быть адрес любой ф-ции из dll, я не пробовал применять эту ф-цию для dll скомпилированных без специальных директив компилятора, отвечающих за размещение кода на страницах, но думаю что сработает.
Во втором случае тебе придется заблокировать страницы юзерского пространства, тут я не могу подсказать что либо конкретное- можешь почитать статью
http://www.osronline.com/article.cfm?id=39 , но не знаю насколько это тебе поможет, у тебя все-таки код отображается, там могут быть относительные адреса к другим модулям, но в таком случае нельзя использовать такие ф-ции для обработки прерывания- оно в контексте любого процесса происходит. Да и Win32 вызывать из режима ядра нельзя. Этот метод не очень подходит.
На обработку прерывания регистрирую ф-ции при помощи IoConnectInterrupt.