Microsoft MVP성태의 닷넷 이야기
.NET Framework: 335. C# - (핸들을 이용하여) 모든 열린 파일을 열람 [링크 복사], [링크+제목 복사]
조회: 24544
글쓴 사람
정성태 (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 시키면 됩니다.
정성태

1  2  [3]  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13559정성태2/19/20242931오류 유형: 895. ASP.NET - System.Security.SecurityException: 'Requested registry access is not allowed.'
13558정성태2/18/20242156닷넷: 2217. C# - 최댓값이 1인 SemaphoreSlim 보다 Mutex 또는 lock(obj)를 선택하는 것이 나은 이유
13557정성태2/18/20241908Windows: 258. Task Scheduler의 Author 속성 값을 변경하는 방법
13556정성태2/17/20241953Windows: 257. Windows - Symbolic (hard/soft) Link 및 Junction 차이점
13555정성태2/15/20242107닷넷: 2216. C# - SemaphoreSlim 사용 시 주의점
13554정성태2/15/20241851VS.NET IDE: 189. Visual Studio - 닷넷 소스코드 디컴파일 찾기가 안 될 때
13553정성태2/14/20241935닷넷: 2215. windbg - thin/fat lock 없이 동작하는 Monitor.Wait + Pulse
13552정성태2/13/20241883닷넷: 2214. windbg - Monitor.Enter의 thin lock과 fat lock
13551정성태2/12/20242079닷넷: 2213. ASP.NET/Core 웹 응용 프로그램 - 2차 스레드의 예외로 인한 비정상 종료
13550정성태2/11/20242164Windows: 256. C# - Server socket이 닫히면 Accept 시켰던 자식 소켓이 닫힐까요?
13549정성태2/3/20242495개발 환경 구성: 706. C# - 컨테이너에서 실행하기 위한 (소켓) 콘솔 프로젝트 구성
13548정성태2/1/20242325개발 환경 구성: 705. "Docker Desktop for Windows" - ASP.NET Core 응용 프로그램의 소켓 주소 바인딩(IPv4/IPv6 loopback, Any)
13547정성태1/31/20242075개발 환경 구성: 704. Visual Studio - .NET 8 프로젝트부터 dockerfile에 추가된 "USER app" 설정
13546정성태1/30/20241936Windows: 255. (디버거의 영향 등으로) 대상 프로세스가 멈추면 Socket KeepAlive로 연결이 끊길까요?
13545정성태1/30/20241852닷넷: 2212. ASP.NET Core - 우선순위에 따른 HTTP/HTTPS 호스트:포트 바인딩 방법
13544정성태1/30/20241863오류 유형: 894. Microsoft.Data.SqlClient - Could not load file or assembly 'System.Security.Permissions, ...'
13543정성태1/30/20241861Windows: 254. Windows - 기본 사용 중인 5357 포트 비활성화는 방법
13542정성태1/30/20241893오류 유형: 893. Visual Studio - Web Application을 실행하지 못하는 IISExpress - 두 번째 이야기
13541정성태1/29/20241938VS.NET IDE: 188. launchSettings.json의 useSSL 옵션
13540정성태1/29/20242067Linux: 69. 리눅스 - "Docker Desktop for Windows" Container 환경에서 IPv6 Loopback Address 바인딩 오류
13539정성태1/26/20242356개발 환경 구성: 703. Visual Studio - launchSettings.json을 이용한 HTTP/HTTPS 포트 바인딩
13538정성태1/25/20242407닷넷: 2211. C# - NonGC(FOH) 영역에 .NET 개체를 생성파일 다운로드1
13537정성태1/24/20242464닷넷: 2210. C# - Native 메모리에 .NET 개체를 생성파일 다운로드1
13536정성태1/23/20242565닷넷: 2209. .NET 8 - NonGC Heap / FOH (Frozen Object Heap) [1]
13535정성태1/22/20242406닷넷: 2208. C# - GCHandle 구조체의 메모리 분석
13534정성태1/21/20242241닷넷: 2207. C# - SQL Server DB를 bacpac으로 Export/Import파일 다운로드1
1  2  [3]  4  5  6  7  8  9  10  11  12  13  14  15  ...