有关Windows 7内核符号的已知问题？ [英] Is there a known issue relating to Windows 7 Kernel Symbols?
问题描述
https://twitter.com/aionescu/status/634028737458114560
我还发现这个： http://support.microsoft.com/kb/2528507
但是，关于文档中给出的wow64exts的方案消息在我的任何一个垃圾场都没有看到。我也不能应用该修补程序在这个时候测试它。所以我只是在寻找更多的信息或意见。
我可以打开任何其他操作系统转储以及我自己的系统的Windows 7转储，但是是另外两台运行Win 7的机器，它告诉我我有错误的内核符号。
我已经尝试清除我的符号缓存，重新安装了Windows SDK，还有试图在其他两台机器上打开转储，结果相同。如果重要，则使用滚动锁定方法手动创建崩溃。
符号路径： SRV * c：\symbols * http：/ /msdl.microsoft.com/download/symbols;
看到这些错误：后跟引用类型：nt！_KPRCB有没有人知道Alex在twitter链接中提到的问题，如果可能与我看到的相关？
更新2015-10-22：
Microsoft补丁日（2015-10-13）和 KB3088195 ，符号再次可用
但是，没有提供破损版本的符号，所以以下可能仍然有用。
Microsoft已经发布了 ntdll 的好符号，其中包含类似信息，如 _TEB 或 _KPRCB 。从2015年7月中旬起，微软仍然发布 ntdll 的符号，但不包含该信息。
所以这取决于 ntdll 的版本，无论您是否获得类型信息。引用旧版本的 ntdll 的旧转储将会下载包含类型信息的旧PDB，而新的转储会引用新版本的 ntdll 和WinDbg（或任何其他调试器）下载没有类型信息的PDB。
Microsoft可以追溯地删除好符号的类型信息，从而使它们坏吗？
是的。如此答案所述，有一种从现有PDB中删除类型信息的工具。
Microsoft可以发布那些目前坏的PDB的好版本吗？ / em>
很难说，因为我们不知道微软是否保留了一个好版本的副本，所以他们可以替换坏版本在符号服务器上带有好的符号。从相同的源代码重建 ntdll ，从而创建新的PDB听起来可能，但是PDB获得了新的时间戳和校验和。这可能会被手动更正，尤其是Microsoft，因为他们应该了解有关PDB内部格式的知识，但是IMHO不太可能这样做。事情可能会出错，MS几乎没有测试来保证这样的事情的正确性。
那我该怎么办？
嗯，你可以不做任何事情，真的正确的情况。
你可以假设 ntdll 中的类型没有太大变化。这将允许您使用旧版本的 wntdll.pdb 和新版本的 ntdll.dll 并应用<一个href =http://www.debuginfo.com/tools/chkmatch.html =nofollow> ChkMatch -m 。这将将时间戳和校验和从DLL复制到PDB。在您执行此操作（在空文件夹中）后，将您的符号目录中现有的 wntdll.pdb 替换为已被黑客攻击的
WinDbg演练（输出缩写为相关内容）。我正在使用最新版本的 wntdll.pdb 我可以在我的电脑上找到。
警告：执行以下操作可能会修复类型信息，但可能会破坏调用堆栈的正确性。由于实施中的任何更改（可能是针对安全修复）将会更改方法偏移量。
0：005> dt nt！_PEB
**************************************** *******************************
*** ***
***你们指定一个不合格的符号，或你的调试器***
...
***引用类型：nt！_PEB ***
*** ***
** ************************************** *********************
未找到符号nt！_PEB。
0：005> lm m ntdll
开始结束模块名称
773f0000 77570000 ntdll（pdb符号）e：\debug\symbols\wntdll.pdb\FA9C48F9C11D4E0894B8970DECD92C972\wntdll.pdb
0：005> .shell cmd / c copy C：\Windows\SysWOW64\\\
tdll.dll e：\debug\temp\\\
tdllhack\\\
tdll.dll
1个文件被复制。
0：005> .shell cmd / c copyE：\Windows SDk\8.0\Debuggers\x86\sym\wntdll.pdb\B081677DFC724CC4AC53992627BEEA242\wntdll.pdbe：\debug\temp\\\
tdllhack \wntdll.pdb
1个文件被复制。
0：005> .shell cmd / c E：\debug\temp\\\
tdllhack\chkmatch.exe -m E：\debug\temp\\\
tdllhack\\\
tdll.dll E：\debug\temp\\\
tdllhack \wntdll.pdb
...
可执行文件：E：\debug\temp\\\
tdllhack\\\
tdll.dll
调试信息文件：E：\debug\temp \\\
tdllhack\wntdll.pdb
可执行文件：
TimeDateStamp：55a69e20
调试信息：2（CodeView）
TimeStamp：55a68c18特征：0 MajorVer：0 MinorVer ：0
大小：35 RVA：000e63e0 FileOffset：000d67e0
CodeView格式：RSDS
签名：{fa9c48f9-c11d-4e08-94b8-970decd92c97}年龄：2
PdbFile：wntdll .pdb
调试信息：10（未知）
TimeStamp：55a68c18特征：0 MajorVer：565 MinorVer：6526
大小：4 RVA：000e63dc FileOffset：000d67dc
调试信息文件：
格式：PDB 7.00
签名：{b081677d-fc72-4cc4-ac53-992627beea24}年龄：4
写入调试信息n文件...
结果：成功。
0：005> .shell cmd / c copy E：\debug\temp\\\
tdllhack\wntdll.pdb E：\debug\symbols\wntdll.pdb\FA9C48F9C11D4E0894B8970DECD92C972\wntdll.pdb
1个文件s）复制。
0：005> .reload
重新加载当前模块
.............................
0：005> dt nt！_PEB
ntdll！_PEB
+ 0x000 InheritedAddressSpace：UChar
+ 0x001 ReadImageFileExecOptions：UChar
...
0：005> ！heap -s
LFH密钥：0x219ab08b
终止损坏：DISABLED
堆标志Reserv Commit Virt自由列表UCR Virt Lock Fast
（k）（k）（k）（k） k）长度块堆
--------------------------------------------- --------------------------------
虚拟块：00920000 - 00920000（大小00000000）
虚拟块：02c60000 - 02c60000（大小00000000）
虚拟块：02e10000 - 02e10000（大小00000000）
...
注意：使用 ChkMatch 像这样有利于您不需要打开 .symopt- 100 ，因为该选项会影响所有PDB文件，并且您不会发现潜在的其他符号问题。如果你不介意使用 .symopt ，你可以简单地复制一个旧的 wntdll.PDB 。
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
I also found this: http://support.microsoft.com/kb/2528507
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.
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.
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.
Symbol path: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols;
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?
Update 2015-10-22:
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 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.
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.
Could Microsoft remove type information of "good" symbols retroactively, thus making them "bad"?
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.
Can Microsoft publish the "good" version of those PDBs which are currently "bad"?
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.
So what can I do?
IMHO you can do nothing to really correct the situation.
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 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:\debug\symbols\wntdll.pdb\FA9C48F9C11D4E0894B8970DECD92C972\wntdll.pdb
0:005> .shell cmd /c copy C:\Windows\SysWOW64\ntdll.dll e:\debug\temp\ntdllhack\ntdll.dll
1 file(s) copied.
0:005> .shell cmd /c copy "E:\Windows SDk\8.0\Debuggers\x86\sym\wntdll.pdb\B081677DFC724CC4AC53992627BEEA242\wntdll.pdb" e:\debug\temp\ntdllhack\wntdll.pdb
1 file(s) copied.
0:005> .shell cmd /c E:\debug\temp\ntdllhack\chkmatch.exe -m E:\debug\temp\ntdllhack\ntdll.dll E:\debug\temp\ntdllhack\wntdll.pdb
...
Executable: E:\debug\temp\ntdllhack\ntdll.dll
Debug info file: E:\debug\temp\ntdllhack\wntdll.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\temp\ntdllhack\wntdll.pdb E:\debug\symbols\wntdll.pdb\FA9C48F9C11D4E0894B8970DECD92C972\wntdll.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)
...
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屋！
