笔记
0工具
0此页用于记录用户反馈问题后的每一次改进
关于
“写笔记”支持四种格式——Word 文档、Excel 表格、Markdown、纯文本，起稿或二次编辑时都能随时切换，同一篇笔记想用哪种形态来记，都由你说了算。
md、txt、csv、json 这类纯文本则原样载入，不做多余加工。拿一张现成的表倒进来、改几笔、再导出去，等于白用一台免费的格式转换器。
要带走就在右上角点“下载”，可导出 PDF、Word、Markdown、Excel、TXT 等格式；列表卡片“⋯”菜单里，也有同样的下载入口。
在“工具”页点“＋ 上传工具”即可发布：填好名称与链接，再用 Markdown 把使用方法写清楚——能解决什么问题、怎么装、怎么用，比堆介绍实在。
要分发安装包就一并上传压缩包（ZIP、RAR、7Z、TAR.GZ，最大 35MB），别人在详情页一键下载；只放链接不带附件也可以。
工具按大家的收藏热度排序，好用的自然会被顶上来。发布后可在详情页或卡片菜单里编辑、下架。
写笔记时勾上“隐藏”，这篇就只存在于你自己的账号里：不进列表、不进搜索、不上首页精选，也不会出现在任何公开的页面，链接发给别人同样打不开。
适合放密码、草稿、日记这类只给自己看的内容；想公开，去“发布”打开它，把“隐藏”的勾去掉再保存，之后编辑会默认保持原状态，不会悄悄变回公开。
不想公开、只想临时给人看：点“分享”生成一条带密码和有效期的链接，到期自动失效，你也能随时撤销。
你的内容会同时保存在多个副本上，系统定期做备份与完整性校验，再配合异地容灾机制：就算某台机器出问题，数据也不会丢，可以长期放心存放；特别重要的资料，仍建议你另外再留一份备份。
全站跑在容器化、模块化的现代架构上，更新、部署、回滚都很快，扩展性和稳定性都按长期运营的标准来设计（Built for reliability, designed to scale）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
老蓝屏，这次学会自己读 minidump 找元凶驱动
之前一直把蓝屏当玄学处理，拍个照、搜下代码、重装驱动碰运气。这次单位那台 Win10 工作机一周蓝了三次，报错还每次不一样，DRIVER_IRQL_NOT_LESS_OR_EQUAL、PAGE_FAULT_IN_NONPAGED_AREA 轮着来，实在没法当偶发了，才沉下心学读 dump。记录一下，免得下次又从零开始。
先保证系统真的在写 dump。Win10 默认是开了小内存转储的，但被优化软件关掉过的话就白搭。检查路径：系统属性(按 Win+Pause 进，或者 sysdm.cpl)→高级→启动和故障恢复→设置→写入调试信息选"小内存转储(256KB)"，转储目录默认 C:\Windows\Minidump。注意这一页里"自动重新启动"的勾很多人会去掉，留着反而好，蓝屏后自动重启能快点回到桌面看 dump。另外系统盘得留够空间、开了页面文件，小转储依赖它。
蓝屏重启后进 C:\Windows\Minidump 看有没有新文件，命名一般是 日期+序号+随机数.dmp，比如 090126-4821-01.dmp。事件查看器里也能捞一条：Windows 日志→系统，按事件 ID 1001 筛，那条的提供程序写的就是 BugCheck，里面带 bugcheck 代码和四个参数，没生成 dump 文件时这个是唯一线索。
读 dump 我用 WinDbg（商店版 WinDbg Preview 就行，老版 WinDbg 也能用）。打开后直接把 dmp 拖进去，等它自动分析完，或者命令行方式：
windbg -z C:\Windows\Minidump\090126-4821-01.dmp
进到命令窗口敲：
!analyze -v
这命令会把分析结果展开一大段，重点看这几行：
BUGCHECK_CODE: d1
BUGCHECK_P1: 0000000000000000
BUGCHECK_P2: fffff80434a11000
PROCESS_NAME: chrome.exe
MODULE_NAME: nvlddmkm
IMAGE_NAME: nvlddmkm.sys
FAILURE_BUCKET_ID: AV_netio!NdisMSendNetBufferListsToOpen
MODULE_NAME / IMAGE_NAME 那两行就是它怀疑的对象。真实案例里我抓到过 nvlddmkm.sys（N 卡驱动）和 netio.sys 的组合——最终定位是某次 Windows 更新后 N 卡驱动和系统的网络驱动在特定操作下撞了，把显卡驱动重装到对应版本才消停。
有个很坑的地方：很常见 IMAGE_NAME 显示 ntoskrnl.exe（内核本体），这时候别急着怪微软。内核镜像永远在调用栈里，!analyze -v 给的 ntoskrnl 往往只是背锅的，要往上翻看 "STACK_TEXT" 里靠前的第三方驱动，或看 FAILURE_BUCKET_ID 里那个模块。有次我看半天 ntoskrnl 以为是系统坏了，结果是某品牌外设的驱动在搞。
想进一步确认嫌疑驱动，在分析输出里找它加载信息：
lmv m nvlddmkm
显示模块路径、时间戳、公司名。第三方驱动通常路径在 C:\Windows\System32\drivers\ 下，时间戳和版本能对上是不是最新。
还有一个工具能当快速通道：BlueScreenView，绿色小软件不用装，扫 Minidump 目录把所有历史蓝屏列成表，哪天的、哪个驱动、dump 文件路径都平铺出来，适合先看全貌再决定要不要上 WinDbg 深挖。
有的蓝屏是偶发、抓不到现行——驱动不老实，平时不出错，特定触发才崩。这时候可以用驱动验证器 Driver Verifier 主动加压，让它把驱动的不规范行为提前炸出来：
verifier /standard /driver 嫌疑驱动.sys
设完重启，它会强制监控目标驱动，出错就直接蓝屏并留下明确指向的 dump。注意这玩意别对全量驱动开，不然正常机器都可能被逼出蓝屏。验完要关：
verifier /reset
整套下来我的顺序：先确认开了小转储 → 复现或等下一次蓝屏 → BlueScreenView 看历史 → WinDbg 拖 dump 跑 !analyze -v → 抓 IMAGE_NAME / FAILURE_BUCKET_ID → 对第三方驱动重装或换版本，ntoskrnl 就继续往 STACK_TEXT 翻。从"拍照搜码"变成"看 dump 定位"，效率高太多。