Coding is hard, you can make it easy!

实在抱歉，因为图床的原因，可能文章中的某些图片看不到，如果需要查看相关图片，请联系我，或者到我的公众号里查看。

我的个人微信号是 BianChengNan，公众号是 编程难。

回首 2023

回顾整个 2023 ，相比 2022 加班少了，工作没那么拼命了。

由于各种原因，年初立的 flag 好几个都没实现。

• 公众号基本上处于鸽的状态
• 也没分享技术视频
• 语言倒是接触了一下 rust，但远没有达到能实战的地步
• 嘴没管住，腿倒是迈开了

展望 2024

我对 2024 这个数字感到非常亲切，2024 = 1000 + 1024，两个一千

• 今年的首要任务依旧是锻炼身体

  本来计划 2024 年跑步作为日常锻炼的方式，结果 2023 年最后一次从公司跑回家后膝盖疼，2024 只能偶尔跑跑了

• 继续遛狗
  2023 花费了很大一部分时间在遛狗上，2024 继续努力。如果不是狗子的陪伴，估计我早抑郁了，感谢，感恩。

• 坚持练习英语口语

  希望这次不要因为任何原因中断

• 继续坚持分享技术文章

  遇到值得总结的问题，及时总结分享

• 读一些非技术书籍

  之前看的书以技术书籍为主，2024 年争取多看些非技术的书籍

• 做一些改变

  尽量熟悉 AI 相关的人和事

缘起

在上篇文章中介绍了在 windbg 中如何查看非常深的调用栈 —— 使用 kN 命令指定栈帧数。kN 虽好，但最多只能查看 0xffff 个栈帧。如果栈帧数量比 0xffff 还多，该如何查看呢？本文将介绍几种查看方法。

缘起

最近，遇到了一个由于递归导致的卡死问题。这个问题非常有意思，值得总结。

你知道什么情况下无限递归会卡死，而不崩溃吗？你知道递归层数过多时，如何找到导致递归调用的函数吗？你知道如何快速找到关键线程吗？你知道如何附加到一个正在被调试的进程吗？你知道如何在 windbg 中显示指定数量的栈帧吗？

带着这些疑问，一起来看看这个非常有意思的问题吧。

说明： 文章末尾有这些问题的答案，可以直接跳到末尾查看。

缘起

我在上一篇文章中介绍了定位抛出异常的理论知识，本文会通过几个实例介绍各种情况下的定位方法。有调试符号如何定位？没有调试符号如何定位？32 位程序如何定位？64 位程序又该如何定位？

其实，32 位程序和 64 位程序定位过程大同小异，只不过在解析过程中需要注意，很多关键字段在 64 位程序中是偏移，需要加上模块基址得到虚拟地址后才能使用，而在 32 位程序中对应的字段就是虚拟地址，可以直接使用。

没有调试符号的时候定位异常类型会比较困难，需要根据上一篇文章中总结的步骤一步步的找到异常类型。有调试符号的情况会比较容易，有很多简便的查看方法。

一起来实战吧！

缘起

最近在分析转储文件时，遇到了一个由 throw 抛出的异常。尽管在 windbg 中使用 !analyze -v 迅速知道了异常码是 0xe06d7363（对应的 ASCII 码是 .msc），但是根据异常码并不能确定具体抛出来的是哪种异常。针对这种情况，确定具体的异常类型才有意义。

本篇文章会简单介绍与抛出异常相关的内容，包括关键的函数及结构体。下一篇文章会通过实例介绍几种典型情况（有调试符号 / 没有调试符号 / 32 位程序 / 64 位程序）下的定位方法。

缘起

之前基于 .net 官方提供的 FileSystemWatcher 写了一个文件变化监听工具，具体参考这篇文章 。主要解决了以下三个问题：

1. 事件触发时，文件可能还不能被访问。
2. 如果监听选项设置的过多，有可能会多次触发文件变化事件。
3. 监听过滤器不够灵活，我没找到同时监听多种特定文件类型的方法（比如，同时只监听 .docx 和 .bmp 文件）。

为了解决问题1，我在调用用户注册的回调函数前，会先调用 WaitUntilCanAccess() 来确保文件是可访问状态。没想到在测试过程中发现了一个意想不到的问题。本文记录了解决这个问题的过程。

前言

前一阵子，我在编写文件变化监控程序的时候遇到了文件被占用的问题。很早之前写过一篇关于 CreateFile 函数的 dwDesiredAccess 和 dwShareMode 参数的笔记。我发现之前的理解不够全面、准确。为了更好的理解这两个参数的作用，我搜索了大量资料，编写了测试程序及测试脚本，参考了 xp 源码，终于搞清楚这两个参数的作用。简而言之，需要遵循以下两个规则：

规则 1：后续的访问权限与先前的共享模式不能冲突。

规则 2：后续的共享模式与先前的访问权限不能冲突。

如果你对下面的几个问题有明确的答案并且清楚的知道原因，那么可以跳过本文了。

1. 第一次以读访问权限，写共享模式打开文件，会成功吗？
2. 如果第一次打开成功了，第二次以写访问权限，读共享模式打开。会成功吗？
3. 如果第二次打开成功了，第三次以读 / 写 / 读写访问权限，读写共享模式打开，会成功吗？
4. 第一次以读访问权限，写共享模式打开文件，第二次以写访问权限，读写共享模式打开。第三次以写访问权限，读写共享模式打开，会成功吗？

缘起

很早之前，我遇到过几个与栈相关的问题，当时总结过几篇关于线程栈的文章，分别是 《栈大小可以怎么改？》、《栈局部变量优化探究，意外发现了 vs 的一个 bug ？》、《栈又溢出了》、《有趣的异常》。在这几篇总结中，简单的总结了栈溢出的原因，设置线程栈大小的方法。但是还有一点没弄清楚：操作系统是怎么知道一个线程的栈大小的？一定记录在某个位置了，否则就不能正确的在栈溢出的时候抛出异常了。不能根据 PE 头中的字段判断，因为在创建线程的时候可以指定线程栈大小。TEB 中的 StackLimit 是真正的栈底吗？带着这些疑问一起来刨根问底吧~

友情提示：结论在文章末尾。

缘起

实际项目中，resource.h 文件中的控件太多太乱了，合并代码的时候非常痛苦。为了解决这个问题，需要对 resource.h 中的 ID 进行整理。根据之前整理的成果，很快把控件 ID 按对话框分类整理好了。没想到测试的时候遇到了各种崩溃，废了好大劲儿才解决。究其原因，是对 MFC 资源管理机制认识不够深刻。尝试创建某个模块内的对话框的时候，意外地找到了其它模块中的对话框资源。MFC 到底是怎么查找资源模块的呢？应该如何排查这种问题呢？一起来看看吧。