Microsoft MVP성태의 닷넷 이야기
.NET Framework: 335. C# - (핸들을 이용하여) 모든 열린 파일을 열람 [링크 복사], [링크+제목 복사],
조회: 24599
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일

(시리즈 글이 5개 있습니다.)
.NET Framework: 335. C# - (핸들을 이용하여) 모든 열린 파일을 열람
; https://www.sysnet.pe.kr/2/0/1338

.NET Framework: 525. C# - 닷넷에서 프로세스가 열고 있는 파일 목록을 구하는 방법
; https://www.sysnet.pe.kr/2/0/10833

.NET Framework: 870. C# - 프로세스의 모든 핸들을 열람
; https://www.sysnet.pe.kr/2/0/12080

.NET Framework: 877. C# - 프로세스의 모든 핸들을 열람 - 두 번째 이야기
; https://www.sysnet.pe.kr/2/0/12107

.NET Framework: 902. C# - 프로세스의 모든 핸들을 열람 - 세 번째 이야기
; https://www.sysnet.pe.kr/2/0/12195




C# - (핸들을 이용하여) 모든 열린 파일을 열람

아시는 것처럼, .NET Framework에서는 기본적으로 프로세스에 열려진 '핸들' 목록을 얻을 수 있는 방법이 없습니다. 사실, 저수준의 핸들이라는 개념 자체가 닷넷에서는 감춰지므로 이해가 됩니다.

대신, P/Invoke를 이용하면 C/C++에서 했던 것과 동일하게 구현을 할 수 있습니다. 마침, Codeplex에서 이와 관련된 소스 코드를 찾아냈는데요.

DetectOpenFiles.cs - CodePlex
; https://vmccontroller.svn.codeplex.com/svn/VmcController/VmcServices/DetectOpenFiles.cs

한 가지 아쉬운 점이라면, 해당 코드가 32비트에서만 동작할 뿐 64비트에서 실행하면 다음과 같은 예외를 발생시킵니다.

System.OverflowException was unhandled by user code
  Message=Arithmetic operation resulted in an overflow.
  Source=mscorlib
  StackTrace:
       at System.IntPtr.op_Explicit(IntPtr value)
       at WebApplication1.DetectOpenFiles.OpenFiles.<GetEnumerator>d__0.MoveNext() in d:\...\WebApplication1\DetectOpenFiles.cs:line 273
       at WebApplication1.WebForm1.Page_Load(Object sender, EventArgs e) in d:\...\WebApplication1\WebForm1.aspx.cs:line 19
       at System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr fp, Object o, Object t, EventArgs e)
       at System.Web.Util.CalliEventHandlerDelegateProxy.Callback(Object sender, EventArgs e)
       at System.Web.UI.Control.OnLoad(EventArgs e)
       at System.Web.UI.Control.LoadRecursive()
       at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
  InnerException: 

다행히 64비트 포팅이 어렵지는 않습니다. 우선, SYSTEM_HANDLE_ENTRY에서 포인터 값이 기존에는 int로 표현되어 있는 것을 IntPtr로 수정해야 합니다.

[StructLayout(LayoutKind.Sequential)]
private struct SYSTEM_HANDLE_ENTRY
{
    public int OwnerPid;
    public byte ObjectType;
    public byte HandleFlags;
    public short HandleValue;
    public IntPtr ObjectPointer;
    public int AccessMask;
}

그 외, handlCount를 읽어들이는 부분에서 4byte가 아닌 8byte를 읽어야 하고,


long handleCount = 0;
if (IntPtr.Size == 4)
{
    handleCount = Marshal.ReadInt32(ptr);
}
else
{
    handleCount = Marshal.ReadInt64(ptr);
}

포인터 처리에 대해서 "(int)ptr"와 같은 표현을 "ptr.ToInt64()"와 같이 바꿔야 합니다.

기타 결정적인 차이점이, "GetFileNameFromHandle" 메서드 안에서 발생하는데요.

private static bool GetFileNameFromHandle(IntPtr handle, out string fileName)
{
    ...[생략]...
    NT_STATUS ret = NativeMethods.NtQueryObject(handle, OBJECT_INFORMATION_CLASS.ObjectNameInformation, ptr, length, out length);
    if (ret == NT_STATUS.STATUS_BUFFER_OVERFLOW)
    {
        ...[생략]...
        ret = NativeMethods.NtQueryObject(handle, OBJECT_INFORMATION_CLASS.ObjectNameInformation, ptr, length, out length);
    }
    if (ret == NT_STATUS.STATUS_SUCCESS)
    {
        fileName = Marshal.PtrToStringUni((IntPtr)((int)ptr + 8), (length - 9) / 2);
        return fileName.Length != 0;
    }
    ...[생략]...
}

위에서 파일 이름을 가져오는 포인터 옵셋값(+8)이 64비트에서는 바뀐다는 점입니다. 정확한 위치를 알기 위해 64비트로 해당 프로그램을 실행시킨 후 ptr.ToInt64() 값을 알아내야 합니다. 디버거의 "Watch" 창을 이용하여 알아낸 값이 "0x00000000022b0930"라고 가정하고 진행했을 때, 이 값을 메모리 윈도우(Ctrl+D,Y) 창에서 확인해 봅니다. 제 경우에는 다음과 같이 나왔습니다.

list_all_file_handle_1.png

보시는 것처럼, 일정 바이트 후에 "\Device\HarddiskVolume2\Windows\assembly\pubpol60.dat"라는 (유니코드) 문자열이 확인되는데, 시작 바이트가 16바이트 이후임을 계산해 낼 수 있습니다. 최종적으로 이를 반영하면 다음과 같은 코드가 나옵니다.

if (IntPtr.Size == 4)
{
    fileName = Marshal.PtrToStringUni((IntPtr)((int)ptr + 8), (length - 9) / 2);
}
else
{
    IntPtr namePtr = new IntPtr(ptr.ToInt64() + 16);
    fileName = Marshal.PtrToStringUni(namePtr);
}

옵셋값은 테스트 결과 다행히 Windows 2003부터 Windows 8까지 전혀 변함없이 사용할 수 있었습니다. 하지만, 코드를 실행하는 권한에 따라서는 범위가 달라지므로 사용 시 이를 감안해야 합니다.

첨부한 프로젝트는 위의 코드를 테스트할 수 있는 간략한 윈폼 프로젝트입니다.

list_all_file_handle_2.png




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







[최초 등록일: ]
[최종 수정일: 6/22/2023]

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

비밀번호

댓글 작성자
 



2017-09-01 07시45분
[최의현] 해당 리스트 Close하려면 혹시 어떻게 해야 하는지 아시나요?
[guest]
2017-09-01 08시30분
[최의현] Process Explorer 에서 아래쪽 패널(하위핸들 - file, Event 등등)에 있는 핸들을 Close시킬 수 있더라구요. 우클릭 - Close Handle
같은 기능을 닷넷에서 구현하려는데 잘 안되어서 자문 구하고자 왔습니다.
[guest]
2017-09-01 03시40분
Close는 Win32 API의 CloseHandle을 이용하시면 PInvoke로 호출하시면 됩니다. 참고로, Process Explorer의 경우 다른 프로세스의 핸들을 닫는 경우인데요. 이럴 때는 반드시 그 프로세스 공간 내에서 실행된 코드를 통해 CloseHandle을 호출해야 합니다. 아마 Process Explorer는 그렇게 했을 것입니다.
정성태
2017-09-04 05시18분
[최의현] 아 그 프로세스 공간에서 해야되는군요.
그걸 놓치고 있었네요.
고유 핸들값이 따로 있는줄 알고 삽질 했네요.
덕분에 잘 배워갑니다. 감사합니다.
[guest]
2019-10-17 07시15분
C# - 닷넷에서 프로세스가 열고 있는 파일 목록을 구하는 방법
; http://www.sysnet.pe.kr/2/0/10833
정성태
2020-03-16 11시46분
해당 프로세스 공간에 침입하지 않고도 다른 프로세스의 핸들을 닫는 방법이 아래의 글에 나와 있습니다.

How can I close a handle in another process?
; https://scorpiosoftware.net/2020/03/15/how-can-i-close-a-handle-in-another-process/

간단하게 정리해 보면, 다른 프로세스의 핸들을 DUPLICATE_CLOSE_SOURCE 옵션을 적용해 DuplicateHandle을 호출한 후 얻은 핸들 값을 CloseHandle 시키면 됩니다.
정성태

... 31  32  33  34  35  36  37  38  39  40  41  42  43  [44]  45  ...
NoWriterDateCnt.TitleFile(s)
12535정성태2/9/20219221개발 환경 구성: 541. Wireshark로 확인하는 LSO(Large Send Offload), RSC(Receive Segment Coalescing) 옵션
12534정성태2/8/20219794개발 환경 구성: 540. Wireshark + C/C++로 확인하는 TCP 연결에서의 closesocket 동작 [1]파일 다운로드1
12533정성태2/8/20219457개발 환경 구성: 539. Wireshark + C/C++로 확인하는 TCP 연결에서의 shutdown 동작파일 다운로드1
12532정성태2/6/20219947개발 환경 구성: 538. Wireshark + C#으로 확인하는 ReceiveBufferSize(SO_RCVBUF), SendBufferSize(SO_SNDBUF) [3]
12531정성태2/5/20218976개발 환경 구성: 537. Wireshark + C#으로 확인하는 PSH flag와 Nagle 알고리듬파일 다운로드1
12530정성태2/4/202113147개발 환경 구성: 536. Wireshark + C#으로 확인하는 TCP 통신의 Receive Window
12529정성태2/4/202110194개발 환경 구성: 535. Wireshark + C#으로 확인하는 TCP 통신의 MIN RTO [1]
12528정성태2/1/20219594개발 환경 구성: 534. Wireshark + C#으로 확인하는 TCP 통신의 MSS(Maximum Segment Size) - 윈도우 환경
12527정성태2/1/20219803개발 환경 구성: 533. Wireshark + C#으로 확인하는 TCP 통신의 MSS(Maximum Segment Size) - 리눅스 환경파일 다운로드1
12526정성태2/1/20217665개발 환경 구성: 532. Azure Devops의 파이프라인 빌드 시 snk 파일 다루는 방법 - Secure file
12525정성태2/1/20217387개발 환경 구성: 531. Azure Devops - 파이프라인 실행 시 빌드 이벤트를 생략하는 방법
12524정성태1/31/20218477개발 환경 구성: 530. 기존 github 프로젝트를 Azure Devops의 빌드 Pipeline에 연결하는 방법 [1]
12523정성태1/31/20218525개발 환경 구성: 529. 기존 github 프로젝트를 Azure Devops의 Board에 연결하는 방법
12522정성태1/31/202110020개발 환경 구성: 528. 오라클 클라우드의 리눅스 VM - 9000 MTU Jumbo Frame 테스트
12521정성태1/31/20219988개발 환경 구성: 527. 이더넷(Ethernet) 환경의 TCP 통신에서 MSS(Maximum Segment Size) 확인 [1]
12520정성태1/30/20218529개발 환경 구성: 526. 오라클 클라우드의 VM에 ping ICMP 여는 방법
12519정성태1/30/20217595개발 환경 구성: 525. 오라클 클라우드의 VM을 외부에서 접근하기 위해 포트 여는 방법
12518정성태1/30/202125050Linux: 37. Ubuntu에 Wireshark 설치 [2]
12517정성태1/30/202112683Linux: 36. 윈도우 클라이언트에서 X2Go를 이용한 원격 리눅스의 GUI 접속 - 우분투 20.04
12516정성태1/29/20219322Windows: 188. Windows - TCP default template 설정 방법
12515정성태1/28/202110553웹: 41. Microsoft Edge - localhost에 대해 http 접근 시 무조건 https로 바뀌는 문제 [3]
12514정성태1/28/202110807.NET Framework: 1021. C# - 일렉트론 닷넷(Electron.NET) 소개 [1]파일 다운로드1
12513정성태1/28/20218866오류 유형: 698. electronize - User Profile 디렉터리에 공백 문자가 있는 경우 빌드가 실패하는 문제 [1]
12512정성태1/28/20218652오류 유형: 697. The program can't start because VCRUNTIME140.dll is missing from your computer. Try reinstalling the program to fix this problem.
12511정성태1/27/20218373Windows: 187. Windows - 도스 시절의 8.3 경로를 알아내는 방법
12510정성태1/27/20218757.NET Framework: 1020. .NET Core Kestrel 호스팅 - Razor 지원 추가 [1]파일 다운로드1
... 31  32  33  34  35  36  37  38  39  40  41  42  43  [44]  45  ...