Microsoft MVP성태의 닷넷 이야기
닷넷: 2290. C# - 간이 dotnet-dump 프로그램 만들기 [링크 복사], [링크+제목 복사],
조회: 8362
글쓴 사람
정성태 (seongtaejeong at gmail.com)
홈페이지
첨부 파일

(시리즈 글이 2개 있습니다.)
닷넷: 2289. "dotnet-dump ps" 명령어가 닷넷 프로세스를 찾는 방법
; https://www.sysnet.pe.kr/2/0/13703

닷넷: 2290. C# - 간이 dotnet-dump 프로그램 만들기
; https://www.sysnet.pe.kr/2/0/13704




C# - 간이 dotnet-dump 프로그램 만들기

이전에 설명한 대로,

"dotnet-dump ps" 명령어가 닷넷 프로세스를 찾는 방법
; https://www.sysnet.pe.kr/2/0/13703

dotnet-dump는 대상 프로세스가 열어놓은 IPC 채널(윈도우: 파이프, 리눅스/MAC: Unix Domain 소켓)을 통해 메모리 덤프를 합니다. github repo에 있는 WriteDump 메서드에 그 과정이 나오는데요,

// .\Microsoft.Diagnostics.NETCore.Client\DiagnosticsClient\DiagnosticsClient.cs
// https://learn.microsoft.com/en-us/dotnet/core/diagnostics/microsoft-diagnostics-netcore-client

public void WriteDump(DumpType dumpType, string dumpPath, WriteDumpFlags flags)
{
    IpcMessage request = CreateWriteDumpMessage(DumpCommandId.GenerateCoreDump3, dumpType, dumpPath, flags);
    IpcMessage response = IpcClient.SendMessage(_endpoint, request);
    if (!ValidateResponseMessage(response, "Write dump", ValidateResponseOptions.UnknownCommandReturnsFalse | ValidateResponseOptions.ErrorMessageReturned))
    {
        request = CreateWriteDumpMessage(DumpCommandId.GenerateCoreDump2, dumpType, dumpPath, flags);
        response = IpcClient.SendMessage(_endpoint, request);
        if (!ValidateResponseMessage(response, "Write dump", ValidateResponseOptions.UnknownCommandReturnsFalse))
        {
            if ((flags & ~WriteDumpFlags.LoggingEnabled) != 0)
            {
                throw new ArgumentException($"Only {nameof(WriteDumpFlags.LoggingEnabled)} flag is supported by this runtime version", nameof(flags));
            }
            request = CreateWriteDumpMessage(dumpType, dumpPath, logDumpGeneration: (flags & WriteDumpFlags.LoggingEnabled) != 0);
            response = IpcClient.SendMessage(_endpoint, request);
            ValidateResponseMessage(response, "Write dump");
        }
    }
}

internal enum DumpCommandId : byte
{
    GenerateCoreDump = 0x01,
    GenerateCoreDump2 = 0x02,
    GenerateCoreDump3 = 0x03,
}

이렇게 GenerateCoreDump3 명령어에 해당하는 메시지를 IPC 채널로 전송한 후, 실패하면 다시 GenerateCoreDump2, 또다시 실패하면 GenerateCoreDump 메시지를 보내게 됩니다. 그러니까, dotnet-dump 자체가 메모리 덤프를 위해 하는 일은 대상 프로세스 스스로 덤프를 뜨도록 신호를 보내는 것뿐이 없습니다.

따라서, 그 과정만 대충 흉내 내면 우리도 dotnet-dump와 유사한 프로그램을 만들 수 있는데요, 실제로 구현을 해보겠습니다. ^^




우선, Dump 하라는 명령어의 구조는 이런 식입니다.

- [byte] CommandSet
- [byte] CommandId
- [byte 배열] Payload 
    - [string] DumpPath
    - [uint] DumpType
    - [uint] Flags

Payload의 구성부터 해볼 텐데요, 간단하게 다음과 같이 처리할 수 있습니다.

DumpCommandId commandId = DumpCommandId.GenerateCoreDump;
byte[] payload = GetPayload(dumpPath, DumpType.Full, 0);

private static byte[] GetPayload(string path, DumpType dumpType, WriteDumpFlags flags)
{
    string data1 = path;
    uint data2 = (uint)dumpType;
    uint data3 = (uint)flags;

    using (MemoryStream stream = new())
    using (BinaryWriter writer = new(stream))
    {
        writer.WriteString(data1);
        writer.Write(data2);
        writer.Write(data3);

        writer.Flush();
        return stream.ToArray();
    }
}

그리고 위의 Payload를 담은 메시지는 대략 이렇게 구성할 수 있습니다.

IpcDiagnosticsMessage msg = new IpcDiagnosticsMessage(DiagnosticsServerCommandSet.Dump, commandId, payload);

public class IpcDiagnosticsMessage
{
    byte _commandSet;
    byte _command;
    public byte CommandId => _command;

    byte[] _payload;
    public byte[] Payload => _payload;

    public IpcDiagnosticsMessage(DiagnosticsServerCommandSet commandSet, DumpCommandId command, byte[] payload)
    {
        _commandSet = (byte)commandSet;
        _command = (byte)command;
        _payload = payload;
    }
}

자, 그럼 저 메시지를 (윈도우의 경우) NamedPipe로 전송하면 되는데요, 이를 위해 NamedPipeClientStream으로 대상 프로세스의 Pipe에 연결하고,

int processId = ...[닷넷 프로세스 ID]...;

string pipeName = $"dotnet-diagnostic-{processId}";
NamedPipeClientStream namedPipe = new(
                    ".",
                    pipeName,
                    PipeDirection.InOut,
                    PipeOptions.None,
                    TokenImpersonationLevel.Impersonation);
namedPipe.Connect();

이후 IpcDiagnosticsMessage를 직렬화해 Stream에 쓰고(Request), 응답(Response)을 받습니다.

SendMessage(namedPipe, msg);
IpcDiagnosticsMessage response = ReceiveResponse(namedPipe);

private static void SendMessage(NamedPipeClientStream namedPipe, IpcDiagnosticsMessage msg)
{
    byte[] packet = msg.Serialize();
    namedPipe.Write(packet, 0, packet.Length);
}

private static IpcDiagnosticsMessage ReceiveResponse(NamedPipeClientStream namedPipe)
{
    using (BinaryReader reader = new(namedPipe, Encoding.UTF8, true))
    {
        return IpcDiagnosticsMessage.Parse(reader);
    }
}

public class IpcDiagnosticsMessage
{
    public const ushort HeaderSizeInBytes = 20;
    private const ushort MagicSizeInBytes = 14;
    public byte[] Magic = DotnetIpcV1; // byte[14] in native code
    public static byte[] DotnetIpcV1 => Encoding.ASCII.GetBytes("DOTNET_IPC_V1" + '\0');

    // ...[생략]...

    public byte[] Serialize()
    {
        byte[]? serializedData = null;

        ushort packetSize = checked((ushort)(HeaderSizeInBytes + _payload.Length));
        byte[] headerBytes = SerializeHeader(packetSize);

        using (MemoryStream stream = new())
        using (BinaryWriter writer = new(stream))
        {
            writer.Write(headerBytes);
            writer.Write(_payload);
            writer.Flush();
            serializedData = stream.ToArray();
        }

        return serializedData;
    }

    byte[] SerializeHeader(ushort packetSize)
    {
        using (MemoryStream stream = new())
        using (BinaryWriter writer = new(stream))
        {
            writer.Write(Magic);
            Debug.Assert(Magic.Length == MagicSizeInBytes);
            writer.Write(packetSize);
            writer.Write(_commandSet);
            writer.Write(_command);
            writer.Write((ushort)0x0000);
            writer.Flush();
            return stream.ToArray();
        }
    }

    public static IpcDiagnosticsMessage Parse(BinaryReader reader)
    {
        byte[] magic = reader.ReadBytes(14);
        ushort size = reader.ReadUInt16();
        byte commandSet = reader.ReadByte();
        byte commandId = reader.ReadByte();
        ushort reserved = reader.ReadUInt16();

        byte[] payload = reader.ReadBytes(size - HeaderSizeInBytes);

        return new IpcDiagnosticsMessage((DiagnosticsServerCommandSet)commandSet, (DumpCommandId)commandId, payload);
    }
}

간단하죠? ^^ 남은 작업은, 응답에 대해 성공 여부를 가려내면 되는데요,

ValidateResponseOptions options = ValidateResponseOptions.None;

switch ((DiagnosticsServerResponseId)response.CommandId)
{
    case DiagnosticsServerResponseId.OK:
        Console.WriteLine($"Supported: {commandId}");
        break;

    case DiagnosticsServerResponseId.Error:
        uint hr = BinaryPrimitives.ReadUInt32LittleEndian(new ReadOnlySpan<byte>(response.Payload, 0, 4));
        Console.WriteLine($"Not supported: {commandId}, hr == {hr:x}");
        // ...[생략]...
        throw new ServerErrorException(message);

    default:
        throw new ServerErrorException($"{commandId} failed - Server responded with unknown response.");
}

Fail 시 반환하는 오류 메시지를 제외하면 사실상 OK, Fail 2가지 상태는 CommandId 필드 하나로 결정할 수 있습니다. 간단하죠?!!! ^^

(첨부 파일은 이 글의 예제 코드를 포함합니다.)




테스트를 하면서 알게 된 사실인데, 현재 윈도우 환경의 .NET Core 3.0 응용 프로그램을 대상으로 위의 코드로 덤프를 시도하면 이런 오류가 발생합니다.

Unhandled exception. Microsoft.Diagnostics.NETCore.Client.UnsupportedCommandException: Write dump failed - Command is not supported.
   at Microsoft.Diagnostics.NETCore.Client.DiagnosticsClient.ValidateResponseMessage(IpcMessage responseMessage, String operationName, ValidateResponseOptions options)
   at Microsoft.Diagnostics.NETCore.Client.DiagnosticsClient.WriteDump(DumpType dumpType, String dumpPath, WriteDumpFlags flags)
   at Microsoft.Diagnostics.NETCore.Client.DiagnosticsClient.WriteDump(DumpType dumpType, String dumpPath, Boolean logDumpGeneration)
   ...[생략]...

그러니까, IPC 채널로 GenerateCoreDump 명령어를 보냈는데 응답으로 DiagnosticsServerResponseId.Error / DiagnosticsIpcError.UnknownCommand 값이 온 것입니다. 다시 말해 .NET Core 3.0 윈도우 앱은 저 채널에 대해 GenerateCoreDump 명령어를 지원하지 않습니다. (반면 리눅스 버전의 .NET Core 3.0은 덤프 명령어를 지원합니다.)

반면, dotnet-dump로 하면 정상적으로 메모리 덤프 파일이 남습니다. 이유가 뭘까요? ^^ 왜냐하면,

// https://github.com/dotnet/diagnostics/blob/main/src/Tools/dotnet-dump/Dumper.cs#L95

// ...[생략]...

if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
{
    if (crashreport)
    {
        Console.WriteLine("Crash reports not supported on Windows.");
        return -1;
    }

    // https://github.com/dotnet/diagnostics/blob/main/src/Tools/dotnet-dump/Dumper.Windows.cs#L16
    Windows.CollectDump(processId, output, type);
}
else
{
    DiagnosticsClient client = new(processId);

    // ...[생략]...
    // Send the command to the runtime to initiate the core dump
    client.WriteDump(dumpType, output, flags);
}

윈도우 버전의 경우 dotnet-dump는 IPC 채널이 아닌 Windows.CollectDump를 호출하고, 그것은 결국 MiniDumpWriteDump Win32 API를 호출하기 때문입니다.

재미있는 건, .NET 5+ 버전부터는 IPC 방식을 윈도우 닷넷 런타임에서 지원함에도 dotnet-dump는 고정적으로 MiniDumpWriteDump를 호출하게 코드가 만들어져 있습니다.

더욱 재미있는 건, 자기 자신에게 IPC 연결을 하는 것도 가능하고, 이를 통해 자기 자신에게 덤프를 뜨는 것도 가능합니다. ^^




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







[최초 등록일: ]
[최종 수정일: 8/6/2024]

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

비밀번호

댓글 작성자
 




... 121  122  123  124  125  126  127  128  129  130  131  [132]  133  134  135  ...
NoWriterDateCnt.TitleFile(s)
1756정성태9/23/201427497기타: 48. NVidia 제품의 과다한 디스크 사용 [2]
1755정성태9/22/201434281오류 유형: 241. Unity Web Player를 설치해도 여전히 설치하라는 화면이 나오는 경우 [4]
1754정성태9/22/201424687VC++: 80. 내 컴퓨터에서 C++ AMP 코드가 실행이 될까요? [1]
1753정성태9/22/201420624오류 유형: 240. Lync로 세미나 참여 시 소리만 들리지 않는 경우 [1]
1752정성태9/21/201441073Windows: 100. 윈도우 8 - RDP 연결을 이용해 VNC처럼 사용자 로그온 화면을 공유하는 방법 [5]
1751정성태9/20/201438964.NET Framework: 464. 프로세스 간 통신 시 소켓 필요 없이 간단하게 Pipe를 열어 통신하는 방법 [1]파일 다운로드1
1750정성태9/20/201423839.NET Framework: 463. PInvoke 호출을 이용한 비동기 파일 작업파일 다운로드1
1749정성태9/20/201423739.NET Framework: 462. 커널 객체를 위한 null DACL 생성 방법파일 다운로드1
1748정성태9/19/201425391개발 환경 구성: 238. [Synergy] 여러 컴퓨터에서 키보드, 마우스 공유
1747정성태9/19/201428522오류 유형: 239. psexec 실행 오류 - The system cannot find the file specified.
1746정성태9/18/201426110.NET Framework: 461. .NET EXE 파일을 닷넷 프레임워크 버전에 상관없이 실행할 수 있을까요? - 두 번째 이야기 [6]파일 다운로드1
1745정성태9/17/201423045개발 환경 구성: 237. 리눅스 Integration Services 버전 업그레이드 하는 방법 [1]
1744정성태9/17/201431070.NET Framework: 460. GetTickCount / GetTickCount64와 0x7FFE0000 주솟값 [4]파일 다운로드1
1743정성태9/16/201420986오류 유형: 238. 설치 오류 - Failed to get size of pseudo bundle
1742정성태8/27/201426986개발 환경 구성: 236. Hyper-V에 설치한 리눅스 VM의 VHD 크기 늘리는 방법 [2]
1741정성태8/26/201421339.NET Framework: 459. GetModuleHandleEx로 알아보는 .NET 메서드의 DLL 모듈 관계파일 다운로드1
1740정성태8/25/201432528.NET Framework: 458. 닷넷 GC가 순환 참조를 해제할 수 있을까요? [2]파일 다운로드1
1739정성태8/24/201426577.NET Framework: 457. 교착상태(Dead-lock) 해결 방법 - Lock Leveling [2]파일 다운로드1
1738정성태8/23/201422069.NET Framework: 456. C# - CAS를 이용한 Lock 래퍼 클래스파일 다운로드1
1737정성태8/20/201419775VS.NET IDE: 93. Visual Studio 2013 동기화 문제
1736정성태8/19/201425597VC++: 79. [부연] CAS Lock 알고리즘은 과연 빠른가? [2]파일 다운로드1
1735정성태8/19/201418274.NET Framework: 455. 닷넷 사용자 정의 예외 클래스의 최소 구현 코드 - 두 번째 이야기
1734정성태8/13/201419939오류 유형: 237. Windows Media Player cannot access the file. The file might be in use, you might not have access to the computer where the file is stored, or your proxy settings might not be correct.
1733정성태8/13/201426367.NET Framework: 454. EmptyWorkingSet Win32 API를 사용하는 C# 예제파일 다운로드1
1732정성태8/13/201434489Windows: 99. INetCache 폴더가 다르게 보이는 이유
1731정성태8/11/201427089개발 환경 구성: 235. 점(.)으로 시작하는 파일명을 탐색기에서 만드는 방법
... 121  122  123  124  125  126  127  128  129  130  131  [132]  133  134  135  ...