北方天空下

最近遇到个问题，回家打开本本后首次打开totalcommander，或者是到公司后第一次启动该程序，进程创建之后界面要等很久才能出来，少则10几秒，多则半分钟。
一直没有头绪也没有去找是啥原因，今天找了下原因，过程是这样：
1.双击运行TC后老问题出现，进程应该有了，但是界面不出来。
2.打开process explore，找到TC的进程，双击打开-》选择Thread标签页，找到主线程，点击Stack。（这个时候界面还没出来。。）
3.Stack内容如下：

ntkrnlpa.exe!KiSwapContext+0x2f
ntkrnlpa.exe!KiSwapThread+0x8a
ntkrnlpa.exe!KeWaitForSingleObject+0x1c2
Mup.sys+0x92e
Mup.sys+0xa3b
Mup.sys+0x6712
Mup.sys+0x644f
Mup.sys+0x6018
[color=red]Mup.sys+0x5829[/color]
[color=red]ntkrnlpa.exe!IopfCallDriver+0x31[/color]
ntkrnlpa.exe!IopParseDevice+0xa12
ntkrnlpa.exe!ObpLookupObjectName+0x53c
ntkrnlpa.exe!ObOpenObjectByName+0xea
ntkrnlpa.exe!IopCreateFile+0x407
ntkrnlpa.exe!IoCreateFile+0x8e
[color=red]ntkrnlpa.exe!NtOpenFile+0x27[/color]
ntkrnlpa.exe!KiFastCallEntry+0xfc
ntdll.dll!KiFastSystemCallRet
ntdll.dll!NtOpenFile+0xc
kernel32.dll!FindFirstFileExW+0x1a7
kernel32.dll!FindFirstFileW+0x16
TOTALCMD.EXE+0x22657
TOTALCMD.EXE+0x228d6
TOTALCMD.EXE+0x1ffb8b
TOTALCMD.EXE+0x201063
TOTALCMD.EXE+0x1cab7b
TOTALCMD.EXE+0x14f2a
TOTALCMD.EXE+0x3bc7b
TOTALCMD.EXE+0x3d6b5
TOTALCMD.EXE+0x3d711
TOTALCMD.EXE+0x3b315
TOTALCMD.EXE+0x22166c
kernel32.dll!BaseProcessStart+0x23

哦，原来是这样，看到Mup.sys大概能猜到一个原因了。Mup.sys这个驱动程序是一个windows内核的驱动程序，当一个应用程序首次尝试打开一个远程机器上的文件的时候，会有一个重定向的过程，比如应用程序访问\\raymond\share这个网络路径，Mup负责告诉确认哪个“重定向器”来负责将这个路径转化为API识别的路径，以便执行。上述Stack的内容显示也正说明了这样一个过程：
1.TC尝试打开某个远程共享的文件或者文件夹
2.依次从应用层传入调用ntdll的NtOpenFile-》调用内核的IopfCallDriver将irp传给文件系统驱动程序，由于是网络路径所以触发了Mup做一次调度转换，而重定向器一直找不到这个远程路径的资源，导致等待，TC因得不到返回所以界面迟迟不能显示。

我才想起来，通常在公司都会打开某个局域网共享服务器，而TC退出的时候有个自动保存当前文件夹的功能，所以我在家首次运行TC的时候它当然找不到了这个公司才有的路径了，从而出现上面的问题。

这是我的推测，不过我没有去证实。

要做这样一次完整的调查最好采用procmon，将TC界面出来之前的这段进程的活动都记录下来，在path一列中一定能找到某个网络路径。而这恰恰正是process explore做不到的，它记录不了过程。

Troubleshooting是一个“大胆假设小心求证”的过程，
不过这次我比较懒，也不打算去弄了，目前先把TC的自动记忆路径的功能禁用。