Microsoft MVP성태의 닷넷 이야기
글쓴 사람
홈페이지
첨부 파일

C# - 닷넷에서 프로세스가 열고 있는 파일 목록을 구하는 방법

프로세스(EXE)에서 열고 있는 파일을 열거하는 방법이 마이크로소프트 코드 사이트에 공개되어 있습니다.

File handle operations demo (CppFileHandle)
; https://code.msdn.microsoft.com/windowsapps/CppFileHandle-03c8ea0b

위의 방법은 C++ 코드인데 이를 보고 PInvoke를 이용해 C#으로 변경할 수 있겠지만 이미 그런 작업을 해둔 분이 계십니다. ^^

Enumerate Open/Locked File Handles by Process
; https://gallery.technet.microsoft.com/scriptcenter/Open-Locked-File-Handles-faffd369

그냥 가져다 쓰시면 됩니다. ^^

방법은 대략 다음과 같은 단계로 요약됩니다.

  1. 임의의 크기로 메모리 할당을 받는다.
  2. 1번 과정에서 할당받은 영역을 NtQuerySystemInformation에 전달. 만약 핸들 정보를 담기에 메모리가 부족하면 4번째 인자에 필요한 메모리의 크기와 함께 STATUS_INFO_LENGTH_MISMATCH를 반환 (성공한 경우 STATUS_SUCCESS(0)을 반환)
  3. 2번 과정에서 STATUS_INFO_LENGTH_MISMATCH가 반환된 경우, 4번째 인자에 해당하는 크기의 메모리를 다시 할당받아 NtQuerySystemInformation에 전달. 이번에도 STATUS_INFO_LENGTH_MISMATCH 반환이 나올 수 있는데, 왜냐하면 1번 호출한 이후 그 와중에 새롭게 핸들이 열렸다면 메모리 크기가 늘어나기 때문.

그런데, 위의 소스코드 모두 특정 환경에서 두번째 NtQuerySystemInformation의 반환값이 STATUS_SUCCESS임에도 불구하고 핸들의 수가 764504201192와 같은 식의 말도 안되는 값이 나오는 경우가 있었습니다. 100% 재현되는 환경은 다음과 같습니다.

  • 윈도우 서버 2012 클린 설치
  • .NET 4.5로 컴파일(.NET 4.0 이하로 컴파일하면 정상 동작)

위의 이유 때문에 ^^ 지난 글이 써진 것입니다.

.NET 4.0과 .NET 4.5의 컴파일 결과 차이점
; https://www.sysnet.pe.kr/2/0/10831

일단, "High Entropy Virtual Addresses" 옵션이 영향을 주긴 했지만 근본적인 문제는 그것이 아니었습니다.




그럼, 원인 파악을 좀 해볼까요? ^^

문제를 쉽게 하기 위해 C++로 다음의 코드를 작성했습니다.

int length = 0x1000;

LPVOID pVoid = ::GlobalAlloc(0, length);

ULONG returnLength = 0;
NTSTATUS ntResult = NtQuerySystemInformation((SYSTEM_INFORMATION_CLASS)16, (LPVOID)pVoid, length, &returnLength);
if (ntResult == STATUS_INFO_LENGTH_MISMATCH)
{
    // Round required memory up to the nearest 64KB boundary. 
    length = ((returnLength + 0xffff) & ~0xffff);
}

::GlobalFree(pVoid);

pVoid = ::GlobalAlloc(0, length);

ntResult = NtQuerySystemInformation((SYSTEM_INFORMATION_CLASS)16, (LPVOID)pVoid, length, &returnLength);
if (ntResult == STATUS_SUCCESS)
{
    __int64 *lResult = (__int64 *)pVoid;
    printf("%I64d\n", *lResult); // 이 값이 바로 열린 핸들의 수를 나타냄
}
else
{
    printf("ntquery failed: %d\n", ntResult);
}

위의 코드를 컴파일해 윈도우 서버 2012 (클린 설치)에서 실행하면 문제가 발생하는 것을 확인할 수 있습니다. 위에서는 GlobalAlloc을 사용했지만 "File handle operations demo (CppFileHandle)" 예제에서처럼 "HeapAlloc(GetProcessHeap(), 0, nSize);" 코드를 사용해도 마찬가지입니다.

제가 가진 윈도우 10에서 실행하면 "123995"와 같은 수가 나오지만 윈도우 서버 2012 R2에서는 "6944656590838556396"와 같은 황당한 수가 나옵니다. 상식적으로 저렇게 많은 핸들이 열렸을 리도 없고 실제로 저 수만 믿고 핸들 정보를 열람하게 되면 STATUS_ACCESS_VIOLATION(0xC0000005) 오류가 발생하게 됩니다.

문제인 즉!

할당된 메모리에 대한 0 초기화가 이뤄져야 한다는 것입니다. 테스트를 위해 두번째 GlobalAlloc(또는 HeapAlloc) 다음에 다음과 같은 코드를 추가하고,

bool allZero = true;
BYTE *pBytes = (BYTE *)pVoid;
for (int i = 0; i < length; i++)
{
    if (*(pBytes) != 0)
    {
        allZero = false;
        break;
    }
}

printf("AllZero == %s\n", (allZero == true) ? "true" : "false");

윈도우 서버 2012 R2(클린 설치)에서 실행하면 "AllZero == false"가 출력되지만 다른 운영체제에서는 "AllZero == true"가 나옵니다.

어쩌면 이건 확률상의 문제일지도 모릅니다. 메모리 할당 함수는 일반적으로 VirtualAlloc으로 큰 영역을 할당받고 그 영역 내에서 GlobalAlloc/HeapAlloc과 같은 메모리 할당 함수가 실제로 필요한 영역의 메모리를 요구하게 됩니다. 운이 좋게도 다른 환경에서는 항상 GlobalAlloc/HeapAlloc으로 요구된 메모리가 기존 할당해 놓은 VirtualAlloc의 영역을 초과해 새롭게 "VirtualAlloc(nullptr, length, MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE);"과 같은 식의 호출을 유발, VirtualAlloc에 의해 최초 메모리가 할당되었을 때는 0으로 초기화가 때문에 문제 없이 NtQuerySystemInformation 호출이 성공한 경우일 수 있습니다.

반면, 윈도우 서버 2012 R2에서는 요청된 2번째 GlobalAlloc/HeapAlloc에서 새로운 메모리가 아닌 기존에 이미 사용중이던 영역의 메모리가 재사용되었고 그곳은 0으로 초기화되지 않았기 때문에 NtQuerySystemInformation 호출에 실패한 것으로 볼 수 있습니다.

실제로 윈도우 서버 2012 R2 이외의 운영체제에서 GlobalAlloc/HeapAlloc으로 할당받았던 메모리에 다음과 같은 식의 쓰레기 값을 채워넣으면 동일한 현상이 재현됩니다.

pVoid = ::HeapAlloc(GetProcessHeap(), 0, length);

BYTE *pBytes = (BYTE *)pVoid;
for (int i = 0; i < length; i++)
{
    *(pBytes + i) = 0x60;
}




결국 해결방법은 ^^ 본문에 나온 것처럼 그냥 0으로 초기화만 해주면 됩니다.

pVoid = ::GlobalAlloc(0, length); // 또는 pVoid = ::HeapAlloc(GetProcessHeap(), 0, length);
memset(pVoid, 0, length);

또는 각각의 함수에서 제공하는 0 초기화 옵션을 사용하면 됩니다.

pVoid = ::GlobalAlloc(GMEM_ZEROINIT, length);

// 또는

pVoid = ::HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, length);

닷넷의 경우 동일한 크기의 byte 배열을 만들어 Marshal.Copy를 하는 방법이 있으나 기왕 Win32 API를 interop해서 호출하는 것이므로 차라리 ZeroMemory Win32 API로 해결하는 것이 더 좋습니다.

[DllImport("Kernel32.dll", EntryPoint = "RtlZeroMemory", SetLastError = false)]
internal static extern void ZeroMemory(IntPtr dest, IntPtr size);
        
ptr = Marshal.AllocHGlobal(length);
ZeroMemory(ptr, new IntPtr(length));

정리하면, NtQuerySystemInformation 함수에 전달할 메모리는 반드시 0으로 초기화 해줄 것!

(첨부한 파일은 이 글의 테스트 코드를 포함합니다.)




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]





[최초 등록일: ]
[최종 수정일: 10/17/2019 ]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer@outlook.com

비밀번호

댓글 쓴 사람
 




[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
12265정성태7/10/202013오류 유형: 629. Visual Studio - 웹 애플리케이션 실행 시 "Unable to connect to web server 'IIS Express'." 오류 발생
12264정성태7/9/202018오류 유형: 628. docker: Error response from daemon: Conflict. The container name "..." is already in use by container "...".
12261정성태7/9/2020153VS.NET IDE: 148. 윈도우 10에서 .NET Core 응용 프로그램을 리눅스 환경에서 실행하는 2가지 방법 - docker, WSL 2 [3]
12260정성태7/8/202057.NET Framework: 926. C# - ETW를 이용한 ThreadPool 스레드 감시파일 다운로드1
12259정성태7/8/202020오류 유형: 627. nvlddmkm.sys의 BAD_POOL_HEADER BSOD 문제
12258정성태7/8/202082기타: 77. DataDog APM 간략 소개
12257정성태7/7/202054.NET Framework: 925. C# - ETW를 이용한 Monitor Enter/Exit 감시파일 다운로드1
12256정성태7/7/202094.NET Framework: 924. C# - Reflection으로 변경할 수 없는 readonly 정적 필드 [4]
12255정성태7/6/202066.NET Framework: 923. C# - ETW(Event Tracing for Windows)를 이용한 Finalizer 실행 감시파일 다운로드1
12254정성태7/2/202036오류 유형: 626. git - REMOTE HOST IDENTIFICATION HAS CHANGED!
12253정성태7/2/2020107.NET Framework: 922. C# - .NET ThreadPool의 Local/Global Queue파일 다운로드1
12252정성태7/2/202085.NET Framework: 921. C# - I/O 스레드를 사용한 비동기 소켓 서버/클라이언트파일 다운로드2
12251정성태7/1/2020110.NET Framework: 920. C# - 파일의 비동기 처리 유무에 따른 스레드 상황파일 다운로드2
12250정성태7/1/2020317.NET Framework: 919. C# - 닷넷에서의 진정한 비동기 호출을 가능케 하는 I/O 스레드 사용법 [1]파일 다운로드1
12249정성태6/29/202035오류 유형: 625. Microsoft SQL Server 2019 RC1 Setup - 설치 제거 시 Warning 26003 오류 발생
12248정성태6/29/202034오류 유형: 624. SQL 서버 오류 - service-specific error code 17051
12247정성태6/29/2020129.NET Framework: 918. C# - 불린 형 상수를 반환값으로 포함하는 3항 연산자 사용 시 단축 표현 권장(IDE0075) [2]파일 다운로드1
12246정성태6/29/202067.NET Framework: 917. C# - USB 관련 ETW(Event Tracing for Windows)를 이용한 키보드 입력을 감지하는 방법
12245정성태6/25/2020227.NET Framework: 916. C# - Task.Yield 사용법 (2) [2]파일 다운로드1
12244정성태6/29/2020101.NET Framework: 915. ETW(Event Tracing for Windows)를 이용한 닷넷 프로그램의 내부 이벤트 활용파일 다운로드1
12243정성태6/23/202064VS.NET IDE: 147. Visual C++ 프로젝트 - .NET Core EXE를 "Debugger Type"으로 지원하는 기능 추가
12242정성태6/24/202039오류 유형: 623. AADSTS90072 - User account '...' from identity provider 'live.com' does not exist in tenant 'Microsoft Services'
12241정성태6/26/2020125.NET Framework: 914. C# - Task.Yield 사용법파일 다운로드1
12240정성태6/23/202095오류 유형: 622. 소켓 바인딩 시 "System.Net.Sockets.SocketException: An attempt was made to access a socket in a way forbidden by its access permissions" 오류 발생
12239정성태6/21/202074Linux: 30. (윈도우라면 DLL에 속하는) .so 파일이 텍스트로 구성된 사례
[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...