オンサイトセミナー
豊田孝の「IT談話館」 Windowsメモリダンプ解析を依頼する WinDbgとシステム分析





メモリ解析サービス



WinDbgとWindowsアーキテクチャー内部解析(1/2)


 本稿では、WinDbgとWindowsアーキテクチャーの関係を取り上げます。Windowsシステム内部解析者とWinDbgの関係などに関しては、本「IT談話館」の「別稿」に譲ります。

 結論を先取りすると、WinDbgとWindowsアーキテクチャーの関係は次のように整理することができます。  「Meltdown and Spectre」などのプロセッサーに起因する問題が顕在化したような場合、プロセッサーを自社生産していないとはいえ、プロセッサーを抽象化しているWindows OSの出荷元であるMicrosoft社は何らかの対策を講じる必要があります。一方、Windowsアプリケーション開発者、技術営業、システム管理者、あるいは、ユーザーサポートなどのIT分野で活動されている方々は、講じられる対策とその影響範囲を把握しておく必要があります。

 まずは、次のようなWindowsアーキテクチャーをおさらいしておくことにします。



 このアーキテクチャー図には、ALPCではなくLPCという旧式の用語が登場しており、一見すると、情報の賞味期限が切れている印象を受けますが、Windowsアーキテクチャーの骨格そのものが劇的に変更されているわけではありません。「Meltdown and Spectre」などのプロセッサーに起因する問題への対策は、この図のどの部分に反映されるのでしょう?

 Windows 10システム環境で採取したActiveメモリダンプに解析コードを適応してみると、次のようなアーキテクチャー内部情報が返されてきます。
Pcr->0xfffff8005a350000	Prcb->0xfffff8005a350180	Process->0xffffd88dffb3c080	Thread->0xffffd88dfef55080	notmyfault64.e
 この情報は、VAD、Session、Section、Token、Job、VM、あるいは、IRPなどの基本概念の多くを捨象し、まさに、Windowsアーキテクチャーの中心概念のみを示しています。上のWindowsアーキテクチャー図でいえば、左から右に向かって、最下位層のHardware Abstraction Layer(HAL)から最上位層のApplicationに相当します。本「IT談話館」は、上記のようなオブジェクト間の微妙な関連性を解析し、Windowsシステムの健康度を診断したり、システムクラッシュ発生原因を特定する高度な技術力を保有しています。

 本稿の本論である「Meltdown and Spectre」問題に入る前の余談になりますが、たとえば、Windowsアーキテクチャー図には、System ServicesやCritical servicesという概念が含まれています。System ServicesはServices.exe(SCM)プロセスの子プロセスですから、その特定は簡単ですが、Critical servicesとはいったいなんでしょう?
 正直に言えば、本「IT談話館」も確かなことは分かりません。しかし、次のような仮説を設定し、それらしい情報を取得することはできます。  これらの仮説を組み入れた解析コードを作成し、Windows 10 Professional環境で採取したActiveメモリダンプに適応すると、次のような情報が返されてきます。
No.001: Parent: 0x002ac	Child: 0x00378	SessionId->0	Critical->1	svchost.exe(0xffffd88dfe647080)
No.002: Parent: 0x002ac	Child: 0x003a0	SessionId->0	Critical->1	svchost.exe(0xffffd88dfd92a080)
No.003: Parent: 0x002ac	Child: 0x004e0	SessionId->0	Critical->1	svchost.exe(0xffffd88dfe9a7080)

TotalProcesses->160


0: kd> !process 0x002ac 0
Searching for Process with Cid == 2ac
PROCESS ffffd88dfe194580
    SessionId: 0  Cid: 02ac    Peb: 3008fc7000  ParentCid: 0268
    DirBase: 135400000  ObjectTable: ffffc70ec84e9980  HandleCount: 704.
    Image: services.exe
 すべての条件をクリアーしたのは、160個のプロセス中、3個だけです。3個のプロセスはすべて「svchost.exe」サービスプロセスですから、なんとなく納得できそうな感じですが、実務解析作業では、「0xffffd88dfe647080」などのプロセス識別情報を頼りにさらに解析作業を進めることになります。たとえば、とりあえず、上記3個の「svchost.exe」プロセスが受け取っているコマンドラインパラメータを調査してみるのも一案です。

+0xFFFFD88DFE647080	svchost.exe
	CommandLine->C:\WINDOWS\system32\svchost.exe -k DcomLaunch -p

+0xFFFFD88DFD92A080	svchost.exe
	CommandLine->c:\windows\system32\svchost.exe -k rpcss -p

+0xFFFFD88DFE9A7080	svchost.exe
	CommandLine->C:\WINDOWS\system32\svchost.exe -k LocalServiceNoNetwork -p
 赤色で強調されている引数はそれぞれの「svchost.exe」サービスプロセスの役割(Service)を指定しています。DcomはDistributed COM、rpcはRemote Procedure Callをそれぞれ示していますから、これらのサービスプロセスが動作を停止した場合、Windowsシステムの運用に深刻(Critical)な影響が出ます。逆に、この2つのプロセスは実質的に動作を停止することはできませんから、内外からのシステム侵入者に「横展開」され、セキュリティー面でのさまざまな危険性が残されていることになります。便利な機能は誰にとっても便利なわけですね。

 最後のLocalServiceNoNetworkは意味不明ですが、次のような解析結果を見ると、LRPC(Local rpc)であることがはっきり分かります。
HandleCount->0502	svchost.exe	ffffd88dfe9a7080
	015: Object->0xffffc70ebd13a640	Name->KnownDlls
	046: Object->0xffffc70ebcfc9ea0	Name->BaseNamedObjects
	061: Object->0xffffd88dfd10adb0	Name->Service-0x0-3e5$
	062: Object->0xffffd88dfcf41260	Name->Default
	063: Object->0xffffd88dfd10adb0	Name->Service-0x0-3e5$
	105: Object->0xffffd88dfe7b64d0	Name->LRPC-1e04123d1c6dafcb51
	108: Object->0xffffd88dfe7cda20	Name->CoreMessagingRegistrar
	110: Object->0xffffd88dfe7cd550	Name->CoreUISystemWindowIDManager
	174: Object->0xffffd88dfdf50970	Name->LRPC-0478b56f5966a113be
	184: Object->0xffffd88dfdf28fe0	Name->BFE_Notify_Event_{f53b9da8-b2b0-4953-ae43-04e69107a58c}
	187: Object->0xffffd88dfdf958c0	Name->BFE_Notify_Event_{0cafbc46-b5ab-4c15-8971-dfda7deb763f}
	191: Object->0xffffd88dfdf98a20	Name->BFE_Notify_Event_{5a40686c-db98-416e-aa26-2f12369eed56}
	193: Object->0xffffd88dfdf95550	Name->BFE_Notify_Event_{7ec53fd7-a69f-4f72-a8f8-be819f2dca7b}
	195: Object->0xffffd88dfdf98400	Name->BFE_Notify_Event_{646dbf31-a7c9-48f1-b3c5-1c9b46d4f9e0}
	212: Object->0xffffc70ec8662fc0	Name->__ComCatalogCache__
	229: Object->0xffffd88dfeaf7b40	Name->BFE_Notify_Event_{bc107dad-a0b3-4993-8525-3244e00dcbf5}
	230: Object->0xffffd88dfb2f6de0	Name->MaximumCommitCondition
	233: Object->0xffffd88dfeaf7b40	Name->BFE_Notify_Event_{bc107dad-a0b3-4993-8525-3244e00dcbf5}
	247: Object->0xffffd88dfdee66c0	Name->BFE_Notify_Event_{3aab5344-00d6-4166-8201-552775602cb5}
	248: Object->0xffffd88dfdee66c0	Name->BFE_Notify_Event_{3aab5344-00d6-4166-8201-552775602cb5}

0: kd> !object 0xffffd88dfe7b64d0
Object: ffffd88dfe7b64d0  Type: (ffffd88dfb31acf0) ALPC Port
    ObjectHeader: ffffd88dfe7b64a0 (new version)
    HandleCount: 1  PointerCount: 32768
    Directory Object: ffffc70ebd466520  Name: LRPC-1e04123d1c6dafcb51
 この解析結果は、LRPCがALPC(Advanced Local Procedure Call)ポートオブジェクトの応用メカニズムであることを示していますから、LocalServiceNoNetworkの意味がここではっきりします。LRPCは、ローカルシステム上で動作するプロセス間にのみ適応される相互通信メカニズムであり、ネットワークサービスを提供していません。このALPCポートオブジェクトを調査したい場合には、たとえば、「!alpc /p 0xffffd88dfe7b64d0」などのWinDbgコマンドを次のように実行します。
0: kd> !alpc /p 0xffffd88dfe7b64d0
Port  ffffd88dfe7b64d0
  Type                      : ALPC_CONNECTION_PORT
  CommunicationInfo         : ffffc70ec8a08c30
    ConnectionPort          : ffffd88dfe7b64d0 (LRPC-1e04123d1c6dafcb51)
    ClientCommunicationPort : 0000000000000000
    ServerCommunicationPort : 0000000000000000
  OwnerProcess              : ffffd88dfe9a7080 (svchost.exe)
  SequenceNo                : 0x00000000 (0)
  CompletionPort            : ffffd88dfe9cf3c0
  CompletionList            : 0000000000000000
  ConnectionPending         : No
  ConnectionRefused         : No
  Disconnected              : No
  Closed                    : No
  FlushOnClose              : Yes
  ReturnExtendedInfo        : No
  Waitable                  : No
  Security                  : Static
  Wow64CompletionList       : No

  10 thread(s) are registered with port IO completion object:

    THREAD ffffd88dfd842080  Cid 04e0.1984  Teb: 00000007c7d36000 Win32Thread: 0000000000000000 WAIT
    THREAD ffffd88dfffc0700  Cid 04e0.1b3c  Teb: 00000007c7dbe000 Win32Thread: 0000000000000000 WAIT
    THREAD ffffd88dfe850080  Cid 04e0.1e68  Teb: 00000007c7c04000 Win32Thread: 0000000000000000 WAIT
    THREAD ffffd88dfc469040  Cid 04e0.1c10  Teb: 00000007c7c18000 Win32Thread: 0000000000000000 WAIT
    THREAD ffffd88e00161080  Cid 04e0.1ff8  Teb: 00000007c7c3e000 Win32Thread: 0000000000000000 WAIT
    THREAD ffffd88dffc22340  Cid 04e0.18ec  Teb: 00000007c7c40000 Win32Thread: 0000000000000000 WAIT
    THREAD ffffd88dff5bc1c0  Cid 04e0.177c  Teb: 00000007c7c42000 Win32Thread: 0000000000000000 WAIT
    THREAD ffffd88e00127200  Cid 04e0.199c  Teb: 00000007c7c44000 Win32Thread: 0000000000000000 WAIT
    THREAD ffffd88dff868080  Cid 04e0.1d7c  Teb: 00000007c7c46000 Win32Thread: 0000000000000000 WAIT
    THREAD ffffd88dff89a700  Cid 04e0.048c  Teb: 00000007c7c48000 Win32Thread: 0000000000000000 WAIT

  Main queue is empty.


  Direct message queue is empty.


  Large message queue is empty.


  Pending queue is empty.


  Canceled queue is empty.
 この出力情報を見ると、ほとんどのキューは「空」ですが、IO完了キューには10個のスレッドが入っています。ここで示されている「10個」という数値は正しいのでしょうか?キューが破損している可能性はないでしょうか?次のようなコマンド操作をすると、これらの疑問への回答を探すことができます。
0: kd> !thread ffffd88dff89a700
THREAD ffffd88dff89a700  Cid 04e0.048c  Teb: 00000007c7c48000 Win32Thread: 0000000000000000 WAIT: (WrQueue) UserMode Alertable
    ffffd88dfe9cf3c0  QueueObject
Not impersonating
DeviceMap                 ffffc70ec7468e30
Owning Process            ffffd88dfe9a7080       Image:         svchost.exe
Attached Process          N/A            Image:         N/A
Wait Start TickCount      4947807        Ticks: 13689 (0:00:03:33.890)
Context Switch Count      1              IdealProcessor: 1             
UserTime                  00:00:00.000
KernelTime                00:00:00.000
Win32 Start Address ntdll!TppWorkerThread (0x00007fff20c642c0)
Stack Init ffffd70a80e0cd90 Current ffffd70a80e0c540
Base ffffd70a80e0d000 Limit ffffd70a80e07000 Call 0000000000000000
Priority 8 BasePriority 8 PriorityDecrement 0 IoPriority 2 PagePriority 5
Child-SP          RetAddr           : Args to Child                                                           : Call Site
ffffd70a`80e0c580 fffff800`5b4b1070 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSwapContext+0x76
ffffd70a`80e0c6c0 fffff800`5b4b09ee : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSwapThread+0x190
ffffd70a`80e0c780 fffff800`5b4af87f : ffffd88d`ff89a700 00000000`00000000 ffffd88d`fe9a7000 ffffd88d`fe9cf3c0 : nt!KiCommitThreadWait+0x10e
ffffd70a`80e0c820 fffff800`5b4af379 : 00000000`00000000 00000000`00000001 00000000`00000001 00000000`00000000 : nt!KeRemoveQueueEx+0x24f
ffffd70a`80e0c8c0 fffff800`5b4aef05 : 00000000`00000000 00000000`00000000 000004e8`fffffb30 000004d0`fffffb30 : nt!IoRemoveIoCompletion+0x99
ffffd70a`80e0c9e0 fffff800`5b596203 : 00000000`00000000 fffff800`5b52062b ffffd88d`fe9cf190 00000000`00000000 : nt!NtWaitForWorkViaWorkerFactory+0x305
ffffd70a`80e0cb90 00007fff`20cd3784 : 00007fff`20c649dd 00000007`c7c9b000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ ffffd70a`80e0cc00)
00000007`d107f4e8 00007fff`20c649dd : 00000007`c7c9b000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!NtWaitForWorkViaWorkerFactory+0x14
00000007`d107f4f0 00007fff`201d1fe4 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!TppWorkerThread+0x71d
00000007`d107f880 00007fff`20c9efb1 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : KERNEL32!BaseThreadInitThunk+0x14
00000007`d107f8b0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x21

0: kd> dt _kqueue ffffd88dfe9cf3c0
ntdll!_KQUEUE
   +0x000 Header           : _DISPATCHER_HEADER
   +0x018 EntryListHead    : _LIST_ENTRY [ 0xffffd88d`fe9cf3d8 - 0xffffd88d`fe9cf3d8 ]
   +0x028 CurrentCount     : 0
   +0x02c MaximumCount     : 4
   +0x030 ThreadListHead   : _LIST_ENTRY [ 0xffffd88d`fd842288 - 0xffffd88d`ff89a908 ]

0: kd> !validatelist ffffd88dfe9cf3c0+30
Found list end after 10 entries
 10個のスレッド数を確認するだけでしたら、このコマンド操作で十分ですが、実務解析作業でこれら10個のスレッド間の関係を解析したいような場合には、次のようなコマンド操作を行うこともあります。
0: kd> dt _io_workitem ffffd88dfe9cf3c0
nt!_IO_WORKITEM
   +0x000 WorkItem         : _WORK_QUEUE_ITEM
   +0x020 Routine          : 0xffffd88d`fe9cf3d8     void  +ffffd88dfe9cf3d8
   +0x028 IoObject         : 0x00000004`00000000 Void
   +0x030 Context          : 0xffffd88d`fd842288 Void
   +0x038 WorkOnBehalfThread : 0xffffd88d`ff89a908 _ETHREAD
   +0x040 Type             : 0
   +0x044 ActivityId       : _GUID {00000000-1000-8948-7c24-184c0e000d02}

0: kd> dt _WORK_QUEUE_ITEM ffffd88dfe9cf3c0
ntdll!_WORK_QUEUE_ITEM
   +0x000 List             : _LIST_ENTRY [ 0x00000000`00100204 - 0xffffd88d`ff5bc300 ]
   +0x010 WorkerRoutine    : 0xffffd88d`ff89a840     void  +ffffd88dff89a840
   +0x018 Parameter        : 0xffffd88d`fe9cf3d8 Void

0: kd> !validatelist poi(0xffffd88dff89a840)
Found list end after 10 entries
 このコマンド操作は、Windowsアーキテクチャー知識、C++のポインターとキャスト(型変換)を応用しています。いずれにしても、「10個」というスレッド数は間違いないようです。「!alpc /p 0xffffd88dfe7b64d0」の代わりに、「!alpc /lpp 0xffffd88dfe9a7080」という具合に、引数としてALPCポートオブジェクトではなく、プロセス識別情報を渡すこともできます。その場合には、次のようなデータを含む、たいへん魅力的な情報が返されてきます。

[---]
		ffffd88dfe7cda20('CoreMessagingRegistrar') 0, 56 connections
		ffffd88dfeb20d40 0 ->ffffd88dfb740670 0 ffffd88dfb91e380('dwm.exe')
		ffffd88dfde38330 0 ->ffffd88dff7dd560 0 ffffd88dfb91e380('dwm.exe')
		ffffd88dfb740e20 0 ->ffffd88dfef20d00 0 ffffd88dfb91e380('dwm.exe')
		ffffd88dfeb1f9d0 0 ->ffffd88dff344390 0 ffffd88dfb24e040('System')
		ffffd88dfef1f5e0 0 ->ffffd88dff5e4320 0 ffffd88dfb91e380('dwm.exe')
		ffffd88dfd1e8e20 0 ->ffffd88dff3a9310 0 ffffd88dfc609080('sihost.exe')
		ffffd88dff74fbb0 0 ->ffffd88dfcf11e20 0 ffffd88dfc609080('sihost.exe')
		ffffd88dfb7bd070 0 ->ffffd88dff5b4070 0 ffffd88dfdc62580('explorer.exe')
		ffffd88dfcdc58d0 0 ->ffffd88dfcfec110 0 ffffd88dfdc62580('explorer.exe')
		ffffd88dfc2b5e20 0 ->ffffd88dfcfa32e0 0 ffffd88dfdc62580('explorer.exe')
		ffffd88dff8786b0 0 ->ffffd88dfbec02f0 0 ffffd88dfc609080('sihost.exe')
		ffffd88dfe938aa0 0 ->ffffd88dfe7c7880 0 ffffd88dff513080('ShellExperienc')
		ffffd88dfb7d3070 0 ->ffffd88dfb740970 0 ffffd88dff513080('ShellExperienc')
		ffffd88dfb3f1220 0 ->ffffd88dfef6ee20 0 ffffd88dfb75e080('SearchUI.exe')
		ffffd88dff5d3e20 0 ->ffffd88dfcff9c60 0 ffffd88dff513080('ShellExperienc')
		ffffd88dfb246580 0 ->ffffd88dfb793470 0 ffffd88dfc99a580('ctfmon.exe')
		ffffd88dfce04bd0 0 ->ffffd88dfd057e20 0 ffffd88dfc99a580('ctfmon.exe')
		ffffd88dfe07ce20 0 ->ffffd88dfd09ee20 0 ffffd88dfc99a580('ctfmon.exe')
		ffffd88dff3cc070 0 ->ffffd88dfd081e20 0 ffffd88dfdc62580('explorer.exe')
		ffffd88dfb9fca80 0 ->ffffd88dfd036990 0 ffffd88dfdc62580('explorer.exe')
		ffffd88dfdccf790 0 ->ffffd88dfdccf070 0 ffffd88dfdc62580('explorer.exe')
		ffffd88dfcec6380 0 ->ffffd88dfcec6650 0 ffffd88dfcfa0580('LockApp.exe')
		ffffd88dfe8c8920 0 ->ffffd88dfea1be20 0 ffffd88dff513080('ShellExperienc')
		ffffd88dfdd9ce20 0 ->ffffd88dfcfc14f0 0 ffffd88dff513080('ShellExperienc')
		ffffd88dffbb3e20 0 ->ffffd88dfd09c8b0 0 ffffd88dff513080('ShellExperienc')
		ffffd88dff7a9310 0 ->ffffd88dfd9b2360 0 ffffd88dff513080('ShellExperienc')
		ffffd88dfffcec10 0 ->ffffd88dffb104b0 0 ffffd88dff513080('ShellExperienc')
		ffffd88dfe19ce20 0 ->ffffd88dfff73e20 0 ffffd88dff513080('ShellExperienc')
		ffffd88dfd101070 0 ->ffffd88dfb842770 0 ffffd88e00052080('chrome.exe')
		ffffd88dfd64dac0 0 ->ffffd88dffcb9a10 0 ffffd88dffef2480('ApplicationFra')
		ffffd88dfdf55870 0 ->ffffd88dffdafe20 0 ffffd88dffc442c0('MicrosoftEdge.')
		ffffd88dfff97070 0 ->ffffd88e001b8070 0 ffffd88dffc442c0('MicrosoftEdge.')
		ffffd88e000a6e20 0 ->ffffd88dfc5dfaf0 0 ffffd88dff9b5080('MicrosoftEdgeC')
		ffffd88dfbb10a30 0 ->ffffd88dff658a70 0 ffffd88dff9b5080('MicrosoftEdgeC')
		ffffd88dfc5e8e20 0 ->ffffd88dffe51070 0 ffffd88dff9b5080('MicrosoftEdgeC')
		ffffd88e0023f6f0 0 ->ffffd88e0023dd60 0 ffffd88dff9f6400('MicrosoftEdgeC')
		ffffd88e0025d070 0 ->ffffd88dfc4013a0 0 ffffd88dff9f6400('MicrosoftEdgeC')
		ffffd88dfc36b7f0 0 ->ffffd88dfb521070 0 ffffd88dfc4c7580('MicrosoftEdgeC')
		ffffd88dfc53a410 0 ->ffffd88e00032bc0 0 ffffd88dfc4c7580('MicrosoftEdgeC')
		ffffd88dfe8f7e20 0 ->ffffd88dff41ae20 0 ffffd88dfc64e580('MicrosoftEdgeC')
		ffffd88dff8f0e20 0 ->ffffd88dfbaf7480 0 ffffd88dfc64e580('MicrosoftEdgeC')
		ffffd88dff466a60 0 ->ffffd88dff5e5830 0 ffffd88dfc4c7580('MicrosoftEdgeC')
		ffffd88dfe93c180 0 ->ffffd88dffa3d520 0 ffffd88dfc4c7580('MicrosoftEdgeC')
		ffffd88e00184070 0 ->ffffd88dffc2be20 0 ffffd88dfc4c7580('MicrosoftEdgeC')
		ffffd88dfc3769c0 0 ->ffffd88dfe9c22c0 0 ffffd88dfce2c440('MicrosoftEdgeC')
		ffffd88dfbc862d0 0 ->ffffd88e000ce190 0 ffffd88dfce2c440('MicrosoftEdgeC')
		ffffd88dff8f4270 0 ->ffffd88dff8968b0 0 ffffd88dff9f6400('MicrosoftEdgeC')
		ffffd88dff979a40 0 ->ffffd88dfba52e20 0 ffffd88dff9f6400('MicrosoftEdgeC')
		ffffd88dfefe4a10 0 ->ffffd88e00021ce0 0 ffffd88dfc50e080('mspaint.exe')
		ffffd88dfb9e8070 0 ->ffffd88dfb953070 0 ffffd88e000972c0('MicrosoftEdgeC')
		ffffd88e00137070 0 ->ffffd88dfbe2c070 0 ffffd88e000972c0('MicrosoftEdgeC')
		ffffd88dfc565550 0 ->ffffd88dffb1ee20 0 ffffd88dffab8400('mshta.exe')
		ffffd88dfdc34d50 0 ->ffffd88e0018fbc0 0 ffffd88dfbb83580('mshta.exe')
		ffffd88dfc319b30 0 ->ffffd88dfb8dd070 0 ffffd88dfdc62580('explorer.exe')
		ffffd88dfc508bf0 0 ->ffffd88dfc5ed470 0 ffffd88dfdc62580('explorer.exe')
		ffffd88dfbed3070 0 ->ffffd88dfbee7070 0 ffffd88dffb3c080('notmyfault64.e')

[---]

 この56個のプロセス接続情報に加え、他の大量の情報が返されてきます。返される情報量はWinDbgコマンド操作ベースの手動解析作業の限界を超え、独自の解析コードを開発し、作業を効率化する必要があります。実務的な解析コード開発技術の習得を目指されている方は、所属チームの上席(決裁権者)を含めた同僚メンバーの皆さんと協議された上で、本「IT談話館」の「オンサイトセミナー」を受講されることをお勧めいたします。時代が求める「高度、かつ、貴重」な技術の習得には、予算と時間の投資が必要です。従来はこのレベルの技術情報の習得には海外文献に頼る必要があったと思いますが、本「IT談話館」主筆の「豊田孝」はBlackHatなどのカンファレンスでプレゼンする海外の先端技術者に助言を与えています。

 余談は以上とし、次のページからWinDbgと「Meltdown and Spectre」問題の本論に入ります。

本論へ


サービスメニュー
Windowsクラッシュダンプ解析サービス WinDbgとWindowsアーキテクチャー内部解析

Copyright©豊田孝 2004- 2018
本日は2018-05-25です。