是否存在与 Windows 7 内核符号相关的已知问题? [英] Is there a known issue relating to Windows 7 Kernel Symbols?
问题描述
我有几台 Windows 7 机器，我无法读取它们的内存转储.我发现了一些我怀疑可能相关的东西，但不是肯定的:
I have a few Windows 7 machines that I am not able to read their memory dumps. I found something that I suspect may be related, but am not positive:
https://twitter.com/aionescu/status/634028737458114560
我也发现了这个:http://support.microsoft.com/kb/2528507
但是，在我的任何转储中都没有看到文档中给出的有关 wow64exts 的场景消息.我目前也无法应用该修补程序来测试它.所以我只是在寻找更多信息或意见.
However, the scenario message regarding wow64exts given in the doc is not seen in any of my dumps. I also cannot apply that hotfix at this time to test it. So I'm just looking for some more information or opinions.
我可以打开任何其他操作系统转储以及我自己系统的 Windows 7 转储，但是还有另外 2 台运行 Win 7 的机器，它告诉我我有错误的内核符号.
I'm able to open any other OS dump as well as my own system's Windows 7 dump, but there are 2 other machines that run Win 7 and it's telling me I have the wrong kernel symbols.
我尝试清除符号缓存，重新安装 Windows SDK，还尝试在其他两台机器上打开转储，结果相同.如果重要，崩溃是使用滚动锁定方法手动创建的.
I have tried clearing out my symbol cache, reinstalled the Windows SDK, and also tried to open the dumps on two other machines with the same result. If it matters, the crash is manually created using the scroll lock method.
符号路径:SRV*c:symbols*http://msdl.microsoft.com/download/symbols;
看到这些错误:后面跟着引用的类型:nt!_KPRCB"
Seeing these errors: followed by "Type referenced: nt!_KPRCB"
有没有人知道亚历克斯在推特链接中提到的问题，以及它是否可能与我所看到的有关?
Does anyone know about the issue mentioned by Alex in the twitter link and if it's possibly related to what I'm seeing?
推荐答案
2015-10-22 更新:
随着 Microsoft 补丁日 (2015-10-13) 和 KB3088195，符号再次可用.
With the Microsoft patch day (2015-10-13) and KB3088195, symbols are available again.
但是，没有提供损坏版本的符号，所以下面可能仍然有用.
However, symbols for the broken version have not been provided, so below may still be useful.
Microsoft 过去已经发布了 ntdll 的良好"符号，其中包含诸如 _TEB 或 _KPRCB 之类的类型信息.从 2015 年 7 月中旬开始，微软仍然发布了 ntdll 的符号，但不包含该信息.
Microsoft has already published "good" symbols for ntdll in the past, containing type information like _TEB or _KPRCB. Starting from mid of July 2015, Microsoft has still published symbols for ntdll, but not containing that information.
因此，是否获取类型信息取决于ntdll 的版本.引用旧版本 ntdll 的旧转储将下载包含类型信息的旧 PDB，而新转储引用新版本的 ntdll 和 WinDbg(或任何其他调试器)下载没有类型信息的 PDB.
So it depends on the version of ntdll whether you get type information or not. Old dumps referencing an old version of ntdll will download old PDBs containing type information while new dumps reference new versions of ntdll and WinDbg (or any other debugger) downloads PDBs without type information.
微软是否可以追溯删除好"符号的类型信息，从而使它们成为坏"符号?
是的.如此答案所述，有一种工具可以从现有 PDB 中删除类型信息.这样做并替换 PDB 会导致这种效果.
Yes. As described in this answer, there is a tool to remove type information from existing PDBs. Doing that and replacing the PDB would result in such an effect.
微软能否发布那些目前坏"的 PDB 的好"版本?
这很难说，因为我们不知道 Microsoft 是否保留了好"版本的副本，以便他们可以用好"版本替换符号服务器上的坏"版本.从相同的源代码重建 ntdll 并因此创建新的 PDB 听起来是可能的，但 PDB 会获得一个新的时间戳和校验和.这可能可以手动更正，尤其是 Microsoft，因为他们应该了解 PDB 内部格式，但恕我直言，他们不太可能这样做.事情可能会出错，MS 几乎没有测试来保证这种事情的正确性.
That's hard to tell, since we don't know whether Microsoft has kept a copy of the "good" version so they could replace the "bad" version on the symbol server with the "good" one. Rebuilding ntdll from the same source code and thus creating new PDBs sounds possible, but the PDB gets a new time stamp and checksum. This can potentially be corrected manually, especially be Microsoft, since they should have the knowledge about the PDB internal format, but IMHO it's unlikely they'll do that. Things may go wrong and MS will hardly have tests to guarantee the correctness of such a thing.
那我该怎么办?
恕我直言，您无法真正纠正这种情况.
IMHO you can do nothing to really correct the situation.
您可以假设 ntdll 中的类型没有发生太大变化.这将允许您采用旧版本的 wntdll.pdb 和新版本的 ntdll.dll 并应用 ChkMatch -m 到它.这会将时间戳和校验和从 DLL 复制到 PDB.完成此操作后(在一个空文件夹中)，将符号目录中现有的 wntdll.pdb 替换为被黑的那个.
You could assume that the types in ntdll have not changed so much. This would allow you to take an older version of wntdll.pdb and the new version of ntdll.dll and apply ChkMatch -m to it. This will copy the timestamp and checksum from the DLL to the PDB. After you did that (in an empty folder), replace the existing wntdll.pdb in your symbols directory with the hacked one.
WinDbg 演练(输出缩短为相关内容).我正在使用可以在我的 PC 上找到的最新版本的 wntdll.pdb.
WinDbg walkthrough (with output shortened to relevant things). I am using the latest version of wntdll.pdb I could find on my PC.
警告:执行以下操作可能会修复类型信息，但可能会破坏调用堆栈的正确性.由于实现中的任何更改(可能用于安全修复)都会更改方法偏移量.
WARNING: doing the following may fix the type information but will likely destroy the correctness of the callstacks. Since any changes in the implementation (which are likely for security fixes) will change the method offsets.
0:005> dt nt!_PEB
*************************************************************************
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
...
*** Type referenced: nt!_PEB ***
*** ***
*************************************************************************
Symbol nt!_PEB not found.
0:005> lm m ntdll
start end module name
773f0000 77570000 ntdll (pdb symbols) e:debugsymbolswntdll.pdbFA9C48F9C11D4E0894B8970DECD92C972wntdll.pdb
0:005> .shell cmd /c copy C:WindowsSysWOW64
tdll.dll e:debug emp
tdllhack
tdll.dll
1 file(s) copied.
0:005> .shell cmd /c copy "E:Windows SDk8.0Debuggersx86symwntdll.pdbB081677DFC724CC4AC53992627BEEA242wntdll.pdb" e:debug emp
tdllhackwntdll.pdb
1 file(s) copied.
0:005> .shell cmd /c E:debug emp
tdllhackchkmatch.exe -m E:debug emp
tdllhack
tdll.dll E:debug emp
tdllhackwntdll.pdb
...
Executable: E:debug emp
tdllhack
tdll.dll
Debug info file: E:debug emp
tdllhackwntdll.pdb
Executable:
TimeDateStamp: 55a69e20
Debug info: 2 ( CodeView )
TimeStamp: 55a68c18 Characteristics: 0 MajorVer: 0 MinorVer: 0
Size: 35 RVA: 000e63e0 FileOffset: 000d67e0
CodeView format: RSDS
Signature: {fa9c48f9-c11d-4e08-94b8-970decd92c97} Age: 2
PdbFile: wntdll.pdb
Debug info: 10 ( Unknown )
TimeStamp: 55a68c18 Characteristics: 0 MajorVer: 565 MinorVer: 6526
Size: 4 RVA: 000e63dc FileOffset: 000d67dc
Debug information file:
Format: PDB 7.00
Signature: {b081677d-fc72-4cc4-ac53-992627beea24} Age: 4
Writing to the debug information file...
Result: Success.
0:005> .shell cmd /c copy E:debug emp
tdllhackwntdll.pdb E:debugsymbolswntdll.pdbFA9C48F9C11D4E0894B8970DECD92C972wntdll.pdb
1 file(s) copied.
0:005> .reload
Reloading current modules
.............................
0:005> dt nt!_PEB
ntdll!_PEB
+0x000 InheritedAddressSpace : UChar
+0x001 ReadImageFileExecOptions : UChar
...
0:005> !heap -s
LFH Key : 0x219ab08b
Termination on corruption : DISABLED
Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast
(k) (k) (k) (k) length blocks cont. heap
-----------------------------------------------------------------------------
Virtual block: 00920000 - 00920000 (size 00000000)
Virtual block: 02c60000 - 02c60000 (size 00000000)
Virtual block: 02e10000 - 02e10000 (size 00000000)
...
注意:像这样使用 ChkMatch 的好处是您不需要打开 .symopt- 100，因为该选项会影响所有 PDB 文件，并且您不会发现潜在的其他符号问题.如果您不介意使用 .symopt，您可以简单地将旧的 wntdll.PDB 复制到新的.
Note: using ChkMatch like this has the benefit that you do not need to turn on .symopt- 100, since that option would affect all PDB files, and you would not find potential other symbol issues. If you don't mind using .symopt, you could simply copy an old wntdll.PDB over the new one.
这篇关于是否存在与 Windows 7 内核符号相关的已知问题?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
