DRIVER_POWER_STATE_FAILURE (9f)

A driver is causing an inconsistent power state.
Arguments:
Arg1: 00000500, The device object completed the irp for the system power
state request, but failed to call PoStartNextPowerIrp.
Arg2: 00000002
Arg3: 8188ab80, Optional Target device's DEVICE_OBJECT
Arg4: 81982d98, DeviceObject

파일 RW를 감시하는 파일시스템 필터 드라이버 작성 중 위의 버그체크 코드를 만났다.
CD Burning을 감시하기 위해, CdRomX에 Attach한 후 시스템을 재 부팅하거나
종료할 때 발생한 문제이다.

WinDbg가 분석해준 내용을 살펴보면 power관련된 처리를 제대로 하지 못했다는 내용인데,
좀 자세히 살펴보자
WinDbg도움말에서 해당 버그첵 코드를 확인해 보면 파라미터 각각에 대한 설명이 상세히 기술되어 있다.

The following parameters appear on the blue screen. Parameter 1 indicates the type of violation.

A driver is causing an inconsistent power state.
(드라이버가 엉터리 파워상태를 야기했다)
Arguments:
Arg1: 00000500, The device object completed the irp for the system power
state request, but failed to call PoStartNextPowerIrp.
(디바이스 오브젝트가 시스템 파워 상태 요청에 대해 irp를 완료하기는 했으나
PoStartNextPowerIrp()를 호출하는 데 실패했다. 머 이런 내용이다.)
Arg2: 00000002
Arg3: 8188ab80, Optional Target device's DEVICE_OBJECT
(이놈은 우리 드라이버가 irp를 잔달한 우리 드라이버의 하위 드라이버의 포인터 이다.)
Arg4: 81982d98, DeviceObject
(문제를 야기한 이놈은 역시나 우리의 드라이버다.)

파일 시스템 드라이버야 WDM이 아닌 레거시 드라이버이다 보니 IRP_MJ_POWER에 대한 별도 처리부분은 없는 상태이고, CdRomX에 Attach한 DeviceObject로 파워관련 IRP가 내려오지 싶다.

역시나 확인을 해보니, 시스템 종료시 CdRomX에 Attach한 디바이스 Object로 IRP_MJ_POWER IRP가 내려온다.

사실 작업 대상이 디바이스가 아닌 파일시스템 쪽이다 보니, POWER,PNP관련 된 부분은 크게 신경 쓰지 않았거덩....(자랑이냐?)

여하간에 WDM 관련 책을 보니 IRP_MJ_POWER 요청에 대해서는 어찌 어찌 하라는 코드가 있더란 말이지...

그래서 IRP_MJ_POWER IRP를 걸러내서 이렇게 변경했다..

일단 문제는 사라졌는데... 좀 더 확인이 필요할것 같다.
현재는 특정 Dispatch함수를 모든 IRP의 디스패치 루틴으로 등록하는 방식인데, IRP_MJ_POWER에 대한 디스패치 루틴을 등록하지 않으면 문제가 발생하지 않을까?

아 그리고, CdRomX에 Attach할때 Attach대상 디바이스 객체의 Flags에 DO_POWER_PAGABLE이 설정되어 있으면, 우리의 디바이스 객체에도 DO_POWER_PAGABLE를 설정해 주어야 한단다.

추측이 다소 포함된 내용이므로 전적으로 신뢰하지 말것...
책임질 수 없음.

IRP_MJ_DEVICE_CONTROL Irp의 완료처리

IRP_MJ_DEVICE_CONTROL IRP의 처리를 완료할 때 사용하는 일반적인(?) 코드이다.

irp->IoStatus.Information와 irp->IoStatus. Status 는 정확히 어떠한 용도로 사용되는가?

드라이버 입문서적을 자세히 읽어 본 사람이라면 잘 알고 있겠지만, 드라이버 개발 초기 많이 실수를 하기도 했던 부분이라 정리해 본다.

n  irp->IoStatus.Status

ü  IRP의 처리 결과를 설정한다. 여기에 설정한 Status값에 따라 User-mode에서 DeviceIoControl()함수를 호출한 후, 이어서 호출하는 GetLastError()의 에러값이 설정된다.

n  irp->IoStatus.Information

ü  Buffered-Methord방식으로 버퍼를 관리하는 DeviceIoCotrol의 경우, 시스템 버퍼에서 user-buffer로 복사되는 사이즈를 기술한다. 예를 들어 irp->AssociatedIrp.SystemBuffer에 10Byte를 복사했더라도 irp->IoStatus.Information에 0을 대입한 후 리턴해 주면, user-buffer에는 어떠한 데이터도 복사되지 않는다.(즉 user-mode에서는 드라이버에서 복사한 내용을 확인 할 수 없다)

FILE_OBJECT의 RelatedFileObject 필드가 유효한 경우

* MSDN의 FILE_OBJECT 섹션을 찾아보면 RelatedFileObject필드는 IRP_MJ_CREATE IRP를 처리하는 시점에서만 유효함을 알 수 있다.

그렇다면 IRP_MJ_CREATE IRP를 처리할때는 RElatedFileObject필드가 항상 유효한가?
MS 문서에 Documentation 되어 있는 내용은 아니지만, 테스트 해보면 다음과 같은 결과를 알수 있다.

1) 절대 경로를 이용하여 파일을 생성하는 경우, [ fopen("E:\\test.txt", _T("w")); ]

FileObject->RelatedFileObject == NULL

FileObject->FileName 필드가 포함하는 값 : 파일경로+파일명 포함

* FullPath를 얻기 위해서는 [볼륨명+FileObject->FileName]의 조합이면 된다.

2) 상대 경로를 이용하여 파일을 생성하는 경우, [ fopen("test.txt", _T("w")); ]

FileObject->RelatedFileObject != NULL

FileObject->RelatedFileObject->FileName 필드가 포함하는 값 : 폴더패스

FileObject->FileName 필드가 포함하는 값 : 파일명

* FullPath를 얻기 위해서는 [볼륨명+FileObject->RelateFileObject+ FileObject->FileName]의 조합이 필요하다.

File System의 로드와 볼륨마운트 과정

1.     파일시스템의 로드

A.     IRP_MJ_FILE_SYSTEM_CONTROL : IRP_MN_MOUNT_VOLUME

B.     IRP_MJ_FILE_SYSTEM_CONTROL : IRP_MN_LOAD_FILE_SYSTEM

2.     볼륨 마운트 - 일반 볼륨

A.     IRP_MJ_FILE_SYSTEM_CONTROL : IRP_MN_MOUNT_VOLUME

B.     IRP_MJ_FILE_SYSTEM_CONTROL : IRP_MN_LOAD_FILE_SYSTEM

C.     Attatch시점

                i.         IRP_MJ_FILE_SYSTEM_CONTROL : IRP_MN_MOUNT_VOLUME

               ii.         볼륨 R/W 감시를 위한 필터 설치

ü  볼륨별 필터 DeviceObject 생성

ü  볼륨별 Device Attatch

3.     볼륨 마운트 - 네트워크 드라이브 볼륨
네트워크 드라이브는 일반 볼륨과는 다른 방식으로 마운트 된다.

A.     Attatch시점

                i.         IRP_MJ_CREATE

ü  DriverName= "\FileSystem\MRxSmb"

ü  DeviceName= "\Device\LanmanRedirector"

               ii.         볼륨 R/W 감시를 위한 필터 설치

ü  모든 네트워크 드라이브 볼륨에 대해 하나의 필터 DeviceObject

*SMB(Server Message Block) - 네트워크를 통해 데이터를 전송 할 수 있도록 클라이언트와 서버 사이에

사용되는 네트워크 프로토콜

Organization of Wdm.h, Ntddk.h, and Ntifs.h

http://msdn.microsoft.com/en-us/library/aa906303.aspx

WDK의 Vista이전 버전에는 드라이버 개발에 쓰이는 메인 header(Wdm.h, Ntddk.h, and Ntifs.h) 들이 중복된 선언을 많이 가지고 있었다.

WDK Vista버전부터 Wdm.h, Ntddk.h, and Ntifs.h 파일들은 중복된 정보를 포함하지 않도록 계층적으로 구성되었다.
higher-level 파일들은 lower-level 파일들을 포함(include)하며 각각의 함수와 구조체들은 단 한번만 선언되어 있다.

Ntifs.h 는 Ntddk.h 를 include하며 Ntddk.h 는Wdm.h를 include한다. 아래의 그림은 이러한 구조를 보여준다.

Diagram illustrating hierarchical header files

Run-time String 함수와 kernel String함수의 대응관계