系统崩溃

为了成功得到系统自动生成的内存转储文件，或者您需要选择生成的转储文件的类型，请务必确保系统中"启动和故障恢复"的相关配置如下： 1、写入小内存转储，如下图所示： 2、写入核心内存转储，如下图所示： "启动和故障恢复"对话框可以通过以下方式打开： 1、单击"开始"菜单，在搜索框内键入"sysdm.cpl"（不带引号）并回车； 2、在打开的"系统属性"对话框内，切换到"高级"选项卡； 3、找到"启动和故障恢复"这个区域，并点击其中的"设置"按钮。 如果您配置的是写入"小内存转储(128k)"，那么在发生系统崩溃并重新启动之后，请上传%SystemRoot%\Minidump文件夹内的.dmp文件，如果文件有很多，请尽量上传最近一到两次的。这里的dump文件名中会有一串数字，表示的是文件生成的日期，格式为"月日年"，您可以据此判断哪些文件是最近生成的。 例如：Mini091909-01.dmp文件是2009年9月19日生成的，031210-15921-01.dmp文件是2010年3月12日生成的。 如果您配置的是写入"核心内存转储"，那么在发生系统崩溃并重新启动之后，请上传%SystemRoot%\MEMORY.DMP这一个文件。上传之前， 请务必压缩它 。 为了能让专业人士更好地帮助您查找系统崩溃原因、解决蓝屏故障，您可以在发表求助帖时将内存转储文件(*.dmp) 于压缩后

原位升级对于许多人来说可能还是个陌生的概念，但覆盖安装相信大家都知道。在Windows 98出现严重问题需要重装系统时，为了避免格式化破坏系统中已经安装的软件和数据，我们通常会使用直接覆盖安装的方式。 　　其实在Windows XP中也有类似覆盖安装的功能，它被称为原位升级，又称修复安装，同样可以在不丢失系统已有数据的情况下重装系统，解决许多严重的系统问题。 　　一、原位升级的方法与实例 　　Windows XP的原位升级使用比Windows 98的覆盖安装要麻烦一些，下面我们通过一个实例来看看具体操作方法。 　　故障现象：一菜鸟好友打来电话，说Windows XP系统无法启动了，匆忙赶去，发现每次刚启动到滚动条界面即自动重启，问其详情，说是昨天安装卸载了许多软件，中间一直没有重启。今天开机就出现了这个现象。推断可能是由于安装卸载软件时破坏了系统，使用最近一次正确配置无法正常启动，尝试安全模式也无法进入，看来只有重装系统了。 　　不过朋友说系统分区中有重要数据还没备份，于是就尝试了一下原位升级，非常顺利地解决了问题。 　　具体步骤：首先使用Windows XP安装光盘启动电脑，根据提示按“Enter”键开始安装Windows XP，然后按F8键接受安装协议，这时安装程序会检测到系统中已经安装有Windows XP，并给出提示，这时按下R键选择修复安装即可

说在开头：文章是我通过查询资料后按照自己的理解总结出来的，所以如果有说法不对的地方，欢迎大佬指正~ 工具 系统：RedHatEnterpriseLinux [RHEL]7.0 ISO镜像文件下载地址：https://www.linuxprobe.com/tools 一、安装VMware Workstation Pro 这个我已经安装好了，我用的是15版本。如果没有安装的，可以去网上找找教程，其实基本上就是点“下一步”。 二、配置VM虚拟机 “新建虚拟机”，“典型”，“稍后安装操作系统”，类型选“Linux”，版本选“Red Hat Enterprise Linux 7 64位”，然后配置成以下样子： 三、安装RHEL 7 系统 教程里面选择的语言是英语，但我选择的中文，为了减少语言造成的困扰。 下面我只放了几个我觉得需要提一下的步骤： Kdump是一个内核崩溃转储机制。在系统崩溃的时候，Kdump将捕获系统信息，这对于诊断崩溃的原因非常有用。注意，Kdump需要预留一部分系统内存，且这部分内存对于其他用户是不可用的。 虽然我的系统语言选择的是中文，但是将系统的输入来源类型还是选择的英语： 以下就是系统的欢迎界面; 至此，RHEL 7 系统完成了全部的安装和部署工作。 来源： CSDN 作者： ISNS 链接： https://blog.csdn.net/u011785309

本文转载自： https://www.cnblogs.com/wayfarer/archive/2004/04/21/6779.html 作者：wayfarer 转载请注明该声明。 昨天开机打开Visual Studio.Net，准备新建一个项目，却发生一件奇怪的事情，系统报告“ auto 对象 .html' target='_self'>mation服务器不能创建对象”错误。 然后在解决方案中只见项目名，而不见项目文件了。真是奇怪。再尝试打开已有项目，却一切正常。 windows应用程序，控制台，或是Web应用程序，都无法建立。 而上周关机之前我还做了项目，不是好好的吗？百思不得其解。无奈之下，只是恢复安装.net。熬过漫长的等待，装好后打开，满以为问题解决了。结果仍然让我郁闷。 横下心，干脆彻底卸载.net，然后重装。又是漫长的等待，结果让我崩溃！！！ 我已经要出离愤怒了。 这时突然才想起google（为什么现在才想起它呢？），将错误作为关键字输入搜索，赫然在第一条就显示天软论坛的贴子，打开一看，真是又高兴有气愤啊。解决之道，原来如此简单。只需要运行：regsvr32 scrrun.dll 就可以了。照方抓药，赶紧运行，再打开.net，一切OK。唉，白白浪费我之前的宝贵光阴啊！ 看情况，应该是关机时出现异常，破坏了影响Automation服务的一个DLL。

这篇文章解释了如何使用驱动程序验证工具来分析崩溃转储文件。 使用Microsoft驱动程序验证工具 如果您曾经使用Windows的调试工具来分析崩溃转储，那么毫无疑问，您已经使用WinDbg打开了一个崩溃转储文件。WinDbg将对崩溃文件执行内部分析，并建议您从!analyze命令开始。该命令输出堆栈以及许多其他信息。执行此操作时，堆栈底部将显示转换为内核模式的线程，然后从那里开始，您向上遍历堆栈以查看是否存在罪魁祸首驱动程序。虽然这是一种可靠的调试技术，但有时崩溃转储或其中的一组将无法分析。内存中没有任何模式可以指出导致系统崩溃的原因，或者内存可能已损坏，因为崩溃转储文件实际上指向Ntsokrnl.exe或win32k.sys。 有一种方法可以通过使用Microsoft驱动程序验证工具将无法处理的崩溃转换为可分析的崩溃。此工具随Windows的每个版本一起提供，不是单独安装的。它不可见，因此不在“开始”菜单或“控制面板”中的“管理工具”中。通过在“开始”菜单的“运行”框中键入“verifier”来启动它，但是为了使用它，您应该知道它是如何工作的。本文将介绍如何使用此工具将无法分析的崩溃转换为可分析的崩溃。驱动程序验证工具包含许多选项，其中一些应该严格避免。 要启动驱动程序验证程序，请在“开始”菜单的“运行”框中键入“Verifier.exe”。第一个数据框显示列表选项

1、使用PLCrashReporter框架 PLCrashReporterConfig *config = [[PLCrashReporterConfig alloc] initWithSignalHandlerType:PLCrashReporterSignalHandlerTypeMach symbolicationStrategy:PLCrashReporterSymbolicationStrategyAll]; PLCrashReporter *reporter = [[PLCrashReporter alloc] initWithConfiguration:config]; NSData *data = [reporter generateLiveReport]; PLCrashReport *report = [[PLCrashReport alloc] initWithData:data error:nil]; NSString *reportStr = [PLCrashReportTextFormatter stringValueForCrashReport:report withTextFormat:PLCrashReportTextFormatiOS]; NSLog(@"%@", reportStr); 2

Crashlog 解析 对于从事iOS移动端测试的同学来说，应用crash十分常见。对于必现crash，通过必现路径复现crash就能定位问题，但对于偶现crash、压力测试crash或者线上crash，就只能通过crashlog来分析，本文介绍iOS端crashlog解析的一些通用知识点。 （做个笔记，以百度地图为例并不适用所有） 1. Crashlog 获取方式 1.1 连接 Xcode 直接读取 crashlog Mac电脑安装Xcode开发平台，通过USB线连接手机与电脑，点击Xcode→Window→De vices and Simulators进入如下界面 （以Xcode9为例）。 图1.1 再点击View Device Logs，读取手机中的crashlog文件。 图1.2 找到对应时间点且process名称为对应app(比如百度地图为IphoneCom)的crashlog文件，右键导出即可。 图1.3 1.2 通过手机直接复制 如果是线上用户主动反馈的crash，那么可能就无法通过上述方式获取crashlog文件，可以让用户进入隐私→诊断与用量→诊断与用量数据查看本地crashlog（iOS10），找到对应时间点且process名称为对应app(比如百度地图为IphoneCom)的文件，并通过手动复制后发送给我们，然后保存成.crash文件。这里有几点需要说明： ①

报错信息为 Failed to open pack file: input/output error 。。。 （很多的failed、卡死在进度条界面） 思路： 1.先进入拯救模式看启动界面按e 进入界面把ro改成 “rw init=/sysroot/bin/sh”. 完成之后按 ctrl+x 进入系统。查看/etc/fatab 挂载情况如有nfs挂载项或者其他挂在项就注释重启 2.如果以没处理掉，就进入自启拯救模式输入 xfs_repair -v -L /dev/dm-0 强制清理脏数据在重启。或者运行xfs_repair /dev//dev/mapper/centos-home xfs_repair/dev/mapper/centos-root xfs_repair/dev/mapper/centos-swap 等命令尝试启动。 来源： https://www.cnblogs.com/jianxgin/p/11761602.html

git很好用，但我很懒 在上家公司的时候，养成了使用git管理项目的好习惯。主分支、版本分支各个RC和Rease版本，每个patch都记录得很得当。所以几乎发布了两年，只出过一二次patch少打的情况，且是因为patch久远，测试时是正好完美避开了bug。 自从开始创业，自己一个人就是团队。号称一个人干了一个团队干的活，基本框架、API框架、小程序、VUE基础的管理平台、VUE基础的合作伙伴平台、Dockefile、Docker编排、Thrift为基础的RPC等等，这些模块加起来有将近10个，也都是一个人一个月完成。 问题很大，我很无奈，但却不是无辜 说到这里我自认为还对得起这10年的工作经验。但是，昨夜的一场发布，让我知道，我还是会犯错，且是一个轻敌的错。因为一个人开发，所以习惯了commit时只用最新版，所以发布时没有关心版本问题。但是昨天是两个版本修选上线，系统是有点不同的，不同有二： 1、主版本（备用版本）没有使用docker、没有使用thrift 2、主版本都使用的是单机配置 很遗憾，我没有给主版本打tag，可以说我自己都不知道是从哪个commit开始的。 因为我认为，我发布的分支版本一定没有问题，并且我准备将此分支版本做主版本。 开始一切顺利，正是我想想的那样。。。 大概晚上8：30时，发布完成，一切就绪；运行也Okay，突然发现，各rpc之间的调用是非常慢的。

最近项目上遇到好几个崩溃问题，解决过程有点曲折，在此记做个记录。 项目背景介绍：该项目为语音识别实时分析系统，整套系统架构如下： 　　 接连几次崩溃的是中间的语音流接入系统，崩溃的情况如下： 1、打开文件过多报错，导致系统直接卡死。 2、打开线程过多，导致系统直接崩溃。 3、Jetty容器异步支持bug。 第一次崩溃：打开文件过多 　　首先在日志中大量的刷屏，因为我们的语音流接入系统只是一个中间转发的服务，这个服务当时是从实时语音分析服务中剥离出来的，当时剥离出来的主要目的是降低实时语音分析服务的带宽压力，所以当出现这个问题后，直接指向的是有网络连接没有释放。 　　既然确定了排查方向，使用lsof命令，好家伙，该进程直接占了六万多个文件句柄，其中eventpoll占了一万六千多个，打开的pipe有三万三千多个，就这两项就占了近五万个句柄。项目上部署的这套系统最高并发为预计的3000路通话，即使在最高通话并发的情况下，也不可能占用这么多句柄数，所以情况就是有连接没有释放，导致句柄泄漏，并逐渐累积到这个数目，验证这个情况，使用netstat，果然发现大量的连接一直没有释放。 　　 　　好了，锁定了目标，接下来就是排查代码中没有正确释放的地方。 　　如最上，一通新通话进来时，我们的语音流接入系统会接入两个语音流并发送给语音识别服务进行识别，在这个过程中，语音流发送是一个持续的过程