w3wp.exe 频繁重启 Faulting application w3wp.exe

有段时间时尔会iis发点小神经.

症状:不知道项目是什么程序造成iis遇到致命问题导致iis应用程序池自动关闭,今天创新高一天死了四次,(这些错误可以去系统事件日志里找到)

在网上找了一方法:

解决办法非常简单,打开应用程序池的属性页,在“回收”选项卡把所有的复选框去掉,让.NET的垃圾回收来管理内存而不要让IIS来插手。

   为应用程序池 'DefaultAppPool' 提供服务的进程关闭时间超过了限制服务器经常产生“应用程序池 'DefaultAppPool' 提供服务的进程关闭时间超过了限制。进程 ID 是 '2068'。”的错误,导致iis处于假死状态,经了解是IIS应用程序池的设置问题。解决方法如下:

Internet 信息服务(IIS)管理器->应用程序池->DefaultAppPool->右击属性

一、回收

1、回收工作进程(分钟):选中,值为1740

2、回收工作进程(请求数目):不选(原先设置为35000)

3、在下列时间回收工作进程:不填

4、消耗太多内存时回收工作进程:全不选。(2、3、4项可能避免了在访问量高的时候强制回收进程可能引发的服务器响应问题,导致iis假死不响应)

二、性能

   只选中空闲超时20分钟。其他都不选。WEB园最大工作进程数为1(默认)。注意web园这里一定要保持默认,如果填写其他超过1的数字就会导致一些网站程序的后台程序打不开或者刷新不停。

   原来的请求队列限制为4000,现在无限制。

三、运行状况

   前两项都起用,是原来的默认设置。启动时间限制90秒,关闭时间限制180秒。

   启动快速失败保护的钩去掉!

   为了避免真的遇到很多错误时没有提示,可以不关闭,只是把快速保护的保护范围加大些,例如失败数50次 时间段5分钟 则关闭对应的程序。

   “关闭时间限制180秒”是必须的,因为进程关闭的时间,原来为90秒限制,是默认值,如果进程关闭时间超过90秒,则认为超时,从而出现:进程关闭时间超过了限制 日志,所以,适当延长这个时间,可以避免这种错误

第2种方法:

   原因:独立进程的 内存堆戋消耗完了,IIS不能创建更多的进程工作空间来处理

   解决方法:

   1. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC

   2. 在Parameters键下新建一个DWORD项,名字为:UseSharedWPDesktop 值为1 重启IIS

第3种

   问题已解决,发现是数据库连接无法释放,不知道是什么原因,同样的代码在本地就是好的,在服务器端就有问题,最后在连接串里加入以下语句解决问题.

   Pooling=true; MAX Pool Size=512;Min Pool Size=50;Connection Lifetime=30

第4种

   新建应用程序池,不同的网站引用不同程序池。

   为应用程序池 'AppPool #1' 提供服务的进程关闭时间超过了限制。进程 ID 是 '3000'。

   出现上面情况后,该应用程序池对应的网站就访问的非常慢,几乎是打不开。

   这种现象是不是iis假死?

   重启下该站点,问题可以得到解决。

   可能是应用程序池设置问题,不知道具体应该怎么设置!

   请高手指点。

   程序代码解决办法:

   1  设置进程池回收时间.在进程池属性里.

   2  如果你的程序是使用 asp + acc 数据库.且acc数据库大于30m.建议更换sql数据库. acc数据库大于这个值.2003系统下会造成iis6的频繁假死.2000下会造成dllhost.exe占用大量cpu及内存资源.都会严重影响web访问速度.

   3  asp程序存在死循环.

   4  可使用 microsoft office 压缩修复acc数据库,须先备份.

引用内容2003应用程序池假死常见问题及解决方法 2006-10-09 09:48   经常见到大家谈起,2003应用程序池自动死了,不能恢复了,一直出现 Service Unavailable 常见方法如下。   1:以前没有SP1打补丁的时候会出现这个IIS6。0假死问题,但现在微软都在自动更新里面出补丁了,一般你打好最新补丁后是不会出现此问题了。(所以现在的IIS假死与这个关系不是很大)   2:从IIS6.0开始CPU资源都在应用池里面限制了,不象以前的IIS。5。所以假死的池的缘故就是池被拉死,你在网站打不开的时候可以看到你的某个应用池是禁用的,上面出现一个红叉。你鼠标右键启动网站又会自动恢复。 这个原因:大概是以下几个因数造成的。     (1):你限制了应用池的资源限制,限制得太小 比如:50这样或更少更多一点,这个时候如果你这个池下面的网站占用CPU太高,比如超过50% 那么5分钟后他就自动死了,手工默认建立的应用池默认是超过资源不操作。      出现上面这个情况解决方法:1:不限制CPU资源,(这个是不可取的,不限制资源,有的程序有BUG占用资源厉害了的,服务器都会被拉死,你可能都无法操作服务器。)2:在超过资源那里选择 关闭,这个关闭默认是失败5次,90秒内恢复,一般默认就可。网站能自动恢复,这个关闭:不是永久关闭,意思是超过资源关闭,然后在某时间内自动恢复池。不操作就是不恢复,这个是很多人的误区。上次我写过相关的这个讲解了。     (2):内存限制 在IIS6。0应用池上面有虚拟内存和最大内存限制,如果你设置了这个。那么网站访问量大了 也会出现假死,所以不建议设置这里。默认就可。   3:就是服务器自身内存太小,网站运行当然需要使用到内存了,当内存不够的时候应用池也会死掉变成禁用。那么只有等内存全部释放出来才能恢复应用池了。出现这个情况:那么你就要考虑加内存或者检查到底是什么程序占用了内存了。比如MSSQL数据库,这个可是吃内存得大户啊,最好别和WEB服务器同时一个服务器上。很多人用1G内存做 2003系统,2003NET结构是很占用内存的,所以做服务器选2003还得把内存加到2G或更高才好。 内存不够上面 2点讲到的,是没办法操作了,也无法自动恢复。   4:就是ACCESS数据库太大或查询太多,这个也会出现把IIS拉死,解决方法;修复ACCESS数据库,或尽量少用ACCESS数据库。   5:不同网站用不同应用池:根据你自己实际情况而定,站点大的最好独立一个应用池,限制他的资源超过了自动回收,看上面 (1)讲到的,这样就不影响其他站点。 中型站点:多个网站共用一个应用池,比如5个站点用一个池,设置他资源时间等等。这样他们就算超资源了也不影响其他应用池的网站。   6:设置回收时间:很多人以为设置回收池越短越好,其实是错误的,每次回收当然是把内存回收回来了,但加重了一次服务器的负担,当服务器比较繁忙的时候,有可能导致其他应用池死。所以建议设置共1000就行了。其他独立池按照他网站流量而设置 可以设置600 也行,共用的不建议设置太短。   7:网站后台过不了多久自动退出又要重新登陆:这个情况就是你设置回收时间太短了,按照 6点设置吧。 不要设置什么20分、30分这样的,这样不好的。

 

 

 

 

 

 

 

 


<think>好的,我现在需要解决用户的问题,即如何打开和分析.dmp文件。首先,用户提到了使用Visual Studio进行调试的引用内容,所以我应该围绕这个工具展开说明。但可能还需要提到其他工具,比如WinDbg,尤其是考虑到用户可能没有VS的情况。 首先,我需要确认.dmp文件是什么。.dmp文件通常是Windows系统或应用程序崩溃时生成的内存转储文件,包含程序崩溃时的内存状态、堆栈信息等,用于调试。接下来,用户想知道如何打开和分析这些文件,所以步骤需要详细,并且要涵盖不同的工具。 根据引用[2],使用Visual Studio需要准备.exe.pdb和.dmp文件。所以第一步是确保这些文件在同一个目录下,或者知道它们的位置。然后,用VS打开.dmp文件,配置符号路径和源文件路径,以便正确解析堆栈跟踪。这里可能需要解释符号文件(.pdb)的作用,因为用户可能不太清楚为什么需要它们。 另外,用户可能遇到的问题是缺少.pdb或源代码,这时候应该如何处理?需要提醒用户,如果没有这些文件,调试会受限,只能看到函数地址而不是具体的代码行。此外,可能需要提到如何设置符号服务器,比如微软的公共符号库,以获取系统DLL的符号。 接下来,如果用户没有Visual Studio,可能需要使用WinDbg。这里需要简要说明WinDbg的安装和使用步骤,比如打开.dmp文件,加载符号,运行命令分析崩溃点。WinDbg的命令如!analyze -v可能需要解释,因为用户可能不熟悉这些命令。 另外,用户可能会问如何生成.dmp文件,虽然当前问题是如何打开,但作为相关问题,可以预见到用户可能需要这个信息。不过根据用户提供的引用[1],他们提到了手动生成dump的方法,但觉得麻烦,所以可能还需要介绍如何自动生成.dmp文件,比如通过SetUnhandledExceptionFilter函数或使用ProcDump工具。 在回答过程中,需要注意用户的技术水平,避免使用过于专业的术语,但又要足够详细,确保步骤清晰。比如,在解释符号文件时,可以说它们帮助调试器将内存地址映射到具体的函数和代码行。 还要检查是否有其他工具或方法,比如使用调试器扩展或第三方工具,但可能主要围绕VS和WinDbg,因为它们是微软官方推荐的。 最后,确保回答结构清晰,分步骤说明,每个工具的使用方法单独列出,并给出注意事项,比如文件版本一致、符号匹配等常见问题。可能还需要提到64位与32位程序的差异,确保使用正确的调试器版本。 总结一下,回答的结构应该是: 1. 使用Visual Studio的步骤,包括准备文件、打开.dmp、配置符号和源代码路径、分析结果。 2. 使用WinDbg的步骤,类似的结构。 3. 注意事项,如文件版本匹配、符号的重要性。 4. 相关问题,可能包括如何生成.dmp文件、常见错误分析、符号服务器配置等。 需要确保所有提到的工具和方法都有明确的步骤,用户能够跟随操作。同时,引用提供的参考资料,特别是引用[2]中的流程,可能需要详细展开,但用户已经给出部分步骤,可以在此基础上补充细节。</think>### 如何打开和分析.dmp文件 .dmp文件是Windows系统或应用程序崩溃时生成的内存转储文件,记录了程序崩溃时的内存状态、堆栈信息等关键数据。以下是使用工具分析和调试.dmp文件的详细步骤: --- #### **一、使用Visual Studio分析.dmp文件** **适用场景**:开发环境已安装Visual Studio,需结合源代码和符号文件定位问题。 **步骤**: 1. **准备文件** - **崩溃程序的可执行文件(*.exe)**:需与生成.dmp文件时的版本完全一致。 - **符号文件(*.pdb)**:包含调试信息,需与.exe文件匹配[^2]。 - **.dmp文件**:崩溃时生成的内存转储文件。 2. **打开.dmp文件** - 启动Visual Studio,选择 **调试 → 打开转储文件**,加载.dmp文件。 3. **配置符号和源代码路径** - **符号路径**:在 **工具 → 选项 → 调试 → 符号** 中添加.pdb文件路径或微软符号服务器(如:`https://msdl.microsoft.com/download/symbols`)。 - **源代码路径**:确保VS能访问崩溃程序的源代码目录。 4. **开始调试** - 点击 **使用仅限本机进行调试**,VS会自动解析崩溃线程的堆栈跟踪。 - 查看 **调用堆栈窗口** 定位到崩溃代码行(需符号和源码匹配)。 ```text 示例输出: Exception thrown at 0x00007FFA1A2345BC in App.exe: 0xC0000005: Access violation reading location 0x0000000000000000. ``` --- #### **二、使用WinDbg分析.dmp文件** **适用场景**:无需源代码,仅需符号文件进行基础分析。 **步骤**: 1. **安装WinDbg** - 通过Windows SDK或Microsoft Store安装 **WinDbg Preview**。 2. **加载.dmp文件** - 打开WinDbg,选择 **File → Open Crash Dump**,选择.dmp文件。 3. **加载符号** - 输入命令:`.sympath srv*C:\Symbols*https://msdl.microsoft.com/download/symbols`(加载微软公共符号)。 - 添加自定义符号路径:`.sympath+ C:\YourProject\bin\Debug`。 4. **分析崩溃点** - 输入 `!analyze -v`,工具会自动分析崩溃原因。 - 使用 `k` 查看堆栈调用链,定位异常模块。 ```text 示例输出: FAULTING_IP: App!SomeFunction+0x1a [C:\Project\App.cpp @ 123] ``` --- #### **三、关键注意事项** 1. **文件版本一致性** - .exe.pdb、.dmp文件必须为同一编译版本,否则调试信息无法匹配。 2. **符号文件的重要性** - 无.pdb文件时,堆栈仅显示内存地址,无法关联到代码行。 3. **区分32/64位程序** - 使用对应位数的调试工具(如64位程序需用x64 WinDbg)。 ---
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值