约有 1,303 项符合查询结果， 以下是第 33 - 131项。
费时 < 1 秒。
赫赫，久等了，希望没辜负你的等待^^
Posted in 《格蠹汇编》
by
格蠹老雷
on 2013-04-17
QQ群是吧？我较少上QQ，如果你愿意创建，可以创建一个，讨论中如果有没解决的问题可以贴到这个论坛，我会尽可能回答......
Posted in 《格蠹汇编》
by
格蠹老雷
on 2013-04-17
1. 简略回答，没有。如果要精确回答，那么要看情况。dump文件是内存的投影，如果当时内存中的目标模块中包含调试符号（比如Borland编译器产生的调试版本DLL），那么这些信息也可能会dump到文件中。因为VC编译器都是把符号单独存放，一般不会加载，也就不大会出现在dump文件中。
2. 根据目标系统，WinDBG会根据dump文件中的模块信息，先找模块，再根据模块中的符号GUID找PDB文件...
Posted in Windows内核调试
by
格蠹老雷
on 2013-04-16
把Ctrl+Alt+D的信息也激活，看出现timetout前是否有可疑的事件发生.
请一个经常做内核调试的同事或者朋友到现场看一下，也许可以更快解决问题。
Posted in Windows内核调试
by
格蠹老雷
on 2013-04-06
如果是干净的系统，那么是有些奇怪的。绝对如此么？
无论如何，可以尝试这样调查：
在能成功断下来时，选Debug > Event Filters调出调试事件配置对话框，选Load module事件，右侧按Command按钮，输入如下命令：
.echo *****module load****;lm;gc
设置好后，让恢复系统运行，然后每当有驱动加载时，应该就有信息输出，等没有信息输出时，再追查加载哪个驱动后就没有显示了（通信断了）...
Posted in Windows内核调试
by
格蠹老雷
on 2013-04-06
WinDBG调试输出说明主机端收不到预期的（类型7）数据包。简单说就是主机端和调试引擎之间的通信断了。这可能和数据线有关，但综合所有信息，还是怀疑某个软件（多半是驱动程序）破坏了串口通信，这也可以解释为什么安全模式时可以，因为安全模式时那个软件可能没有得到运行机会。
Posted in Windows内核调试
by
格蠹老雷
on 2013-04-06
1，也可能是调用你的filter，filter返回后，继续向下传
2，没有错
3，没有错，84ec6a60要获取Paging resource，但已经被线程84e47830获取了。后者在用FltSendMessage与用户态通信，但用户态的线程可能就是触发了文件访问而被阻塞住的84ec6a60或者86b1cc10...
Posted in Windows内核调试
by
格蠹老雷
on 2013-04-05
首先值得注意的是，VC中既支持SEH，又支持C++的异常机制，二者是有很多不同的。写作这一章时，两种异常机制都讨论了，但是因为篇幅太长做删节时，将C++的异常机制删掉了，后来放到了补编电子版中。
http://advdbg.org/books/download/rjts_sup.pdf
因此，建议看一下上面补编内容的P32页。
0x19930520是VC++模拟出的异常结构中的Magic Code，补编中也有介绍（至于这个日期暗示着什么有待考证）。
很好的学习方法，继续坚持探索，就要豁然开朗了^^
Posted in C/C++本地代码调试
by
格蠹老雷
on 2013-04-05