Coding is hard, you can make it easy!

缘起

vs有一个功能 —— 在起始页会显示最近打开的工程列表，方便用户快速打开之前打开过的工程文件。但是打开的工程文件多了，想要找到自己需要的工程文件也不是那么容易的，要是能把之前打开的记录都清理干净该有多好啊。本文记录了我在查找vs2019相关设置存储位置的调查过程 。对于vs2017以前的版本，对应的设置是保存在注册表中的，从vs2017开始，不再保存在注册表，而是存储在本地配置文件中。到底存储在哪里了呢？我们一起来看看吧！

前言

这是几年前在项目中遇到的一个崩溃问题，崩溃在了ComFriendlyWaitMtaThreadProc()里，没有源码。耗费了我很大精力，最终通过反汇编并结合原代码才最终搞清楚了事情的来龙去脉。本文的分析还是基于真实项目进行的，中间略去了很多反汇编的分析工作。文末有我整理的测试代码，大家可以实际体验一把TerminateThread()的杀伤力。

缘起

最近，我们程序的某个功能在一台机器上不正常，但是在另外一台机器上却是正常的。代码是同一份，vs版本也一样（打的补丁也一样）。编译出来的程序在两台电脑上运行的结果就是不一样。惊不惊喜，意不意外？如果是你遇到了这种情况，你会怎么调查呢？:upside_down_face:

缘起

最近同事使用.tsep安装Tekla插件的时候，Tekla提示该插件已经存在了，需要卸载后再安装。同事找了半天，没找到怎么卸载，我也没找到。于是决定弄清楚Tekla是 如何判断一个插件安装与否的。 想必看过我其它排错文章的小伙伴已经猜到了，我们今天文章中的主角依然是process monitor。好了，话不多说，好戏马上开始。

缘起

最近想借助IDA逆向一个函数。在windows下，调试器（比如vs, windbg）可以通过调试符号（PDB）把地址与符号名对应起来，为我们提供更可读的信息。IDA应该也支持加载PDB，通过查看IDA安装目录下的idahelp.chm（打开后搜索PDB即可找到相关说明）发现还真支持。但是当我加载符号的时候，却失败了。本文记录了整个调查过程。

前言

最近我们的程序在退出时会卡住，调查发现是在卸载dll时死锁了。大概流程是这样的：我们的dll在加载的时候会创建一个工作线程，在卸载的时候，会设置退出标志并等待之前开启的工作线程结束。为了研究这个经典的死锁问题，写了一个模拟程序，用到的dump文件及示例代码参考附件。

前言

项目里的一个升级程序偶尔会死锁，查看dump后发现是死在了ShellExecuteExW里。经验少，不知道为什么，于是在高端调试论坛里发帖求助，链接如下http://advdbg.org/forums/6520/ShowPost.aspx

根据张银奎老师的描述可知，应该是拥有关键段的线程意外结束了。仔细检查项目中的代码，发现程序中有使用TerminateThread()来强制杀线程的代码。很可疑，于是写了一个测试程序，还原了这个问题。

前言

这是几年前在项目中遇到的一个死锁问题，在博客园发布过。我对之前的笔记进行了整理重新发布于此。
本文假设小伙伴们知道一些基本概念，比如什么是.dump文件（转储文件，进程在某一时刻的快照），什么是windbg（windows下的调试利器），windbg的基本用法，调用栈，调用约定，等等。

缘起

最近在编译项目的时候总是报虚拟内存不足（项目中使用了大量的模板）。一般情况下，vs会使用32位的编译工具进行编译，用64位的编译工具应该能解决类似的问题。本以为是一件挺简单的事，但是没想到遇到不少坑，本文记录了折腾的过程，希望对有类似需求的小伙伴有所帮助。

缘起

最近项目中遇到一个诡异的问题，程序在升级到.net4.6.1后，执行某个功能时会崩溃，提示访问只读内存区。大概规律如下:

1. debug版不崩溃，release版稳定崩溃。
2. 只有x64位的程序崩溃，32位及anycpu编译出来的程序运行不会崩溃。
3. 出问题的代码范围很小（按钮点击事件代码不多）。

根据以上信息，各位小伙伴有什么思路吗？