记一次 .NET 某零售管理系统 存储不足分析

这篇具有很好参考价值的文章主要介绍了记一次 .NET 某零售管理系统 存储不足分析。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

一:背景

1. 讲故事

前几天有位朋友找到我,说他的程序会偶发性的报 存储空间不足,无法处理此命令 的错误,让我帮忙看下到底怎么回事,哈哈,人家是有备而来,dump都准备好了,话不多说,直接分析开干。

二:WinDbg 分析

1. 捕获dump中的异常

一般来讲别人说的只是一个参考,我们需要自己到dump中去验证,可以用 !t 观察下。


0:000:x86> !t
ThreadCount:      61
UnstartedThread:  0
BackgroundThread: 52
PendingThread:    0
DeadThread:       3
Hosted Runtime:   no
                                                                         Lock  
       ID OSID ThreadOBJ    State GC Mode     GC Alloc Context  Domain   Count Apt Exception
   0    1 9310 004e24f8     26020 Preemptive  00000000:00000000 004d94e0 0     STA System.Runtime.InteropServices.COMException 42b57774 (nested exceptions)
   ...

0:000:x86> !PrintException /d 42b57774
Exception object: 42b57774
Exception type:   System.Runtime.InteropServices.COMException
Message:          存储空间不足,无法处理此命令。 (Exception from HRESULT: 0x80070008)
InnerException:   <none>
StackTrace (generated):
    SP       IP       Function
    00000000 00000001 mscorlib_ni!System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32, IntPtr)+0x2
    003FAC0C 6F5655C9 mscorlib_ni!System.Runtime.InteropServices.Marshal.ThrowExceptionForHR(Int32, IntPtr)+0x9
    003FAC10 55171671 PresentationCore_ni!MS.Internal.Text.TextInterface.Native.Util.ConvertHresultToException(Int32)+0x702961
    003FAC24 54A56129 PresentationCore_ni!MS.Internal.Text.TextInterface.FontFace.GetDesignGlyphMetrics(UInt16*, UInt32, MS.Internal.Text.TextInterface.GlyphMetrics*)+0x79
    003FAC60 54A73B77 PresentationCore_ni!System.Windows.Media.GlyphTypeface.GlyphMetrics(UInt16*, Int32, MS.Internal.Text.TextInterface.GlyphMetrics*, Double, System.Windows.Media.TextFormattingMode, Boolean)+0x47
    ...

从卦中信息看确实抛了一个 COMException 异常,并且真的有这么一条错误信息 存储空间不足,无法处理此命令,而且从调用栈来看貌似是wpf在处理 字形信息,一般来说这种代码是千锤百炼不会出任何问题的。

作为现代化的程序员,必须通过 百度搜索 寻找一下天涯沦落人,通过搜索得知大概有两种情况:

  • 硬盘存储空间不足所致
  • 内存不足所致

记一次 .NET 某零售管理系统 存储不足分析

2. 是硬盘存储空间不足吗

要想验证是不是这种情况导致的,只能询问下朋友,据朋友反馈不存在这个问题,所以这条路就堵死了。

3. 是内存不足吗

要想排查这种情况只能观察进程的 MEM_COMMIT 指标,使用 !address -summary


0:000:x86> !address -summary
...
--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_COMMIT                             3773          6e617000 (   1.725 GB)  89.86%   86.24%
MEM_RESERVE                             702           c4c6000 ( 196.773 MB)  10.01%    9.61%
MEM_FREE                                667           5513000 (  85.074 MB)            4.15%
...
--- Largest Region by Usage ----------- Base Address -------- Region Size ----------
Heap32                                      23470000            fd0000 (  15.812 MB)
<unknown>                                   474b0000           19c4000 (  25.766 MB)
Image                                       2fbf1000           1180000 (  17.500 MB)
Free                                        7355b000            1a5000 (   1.645 MB)
Stack32                                       c50000             fd000 (1012.000 kB)
Stack64                                       5a0000             39000 ( 228.000 kB)
Other                                         8e0000            181000 (   1.504 MB)
TEB64                                       7ee37000              2000 (   8.000 kB)
Heap64                                        120000             65000 ( 404.000 kB)
TEB32                                       7ee39000              1000 (   4.000 kB)
Other32                                       290000              1000 (   4.000 kB)
PEB64                                       7efdf000              1000 (   4.000 kB)
PEB32                                       7efde000              1000 (   4.000 kB)
...

从卦中的信息看,当前程序提交内存是 1.7G ,看到这个值马上就想到了 2G虚拟地址,那这个程序是不是x86的呢?除了观察内存地址,也可以通过观察 PE 头获知。


0:000:x86> lm 
start    end        module name
01380000 01450000   xxxWinApp C (no symbols)       

0:000:x86> !dh xxxWinApp 

File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
     14C machine (i386)
       3 number of sections
654073AD time date stamp Tue Oct 31 11:25:33 2023

       0 file pointer to symbol table
       0 number of symbols
      E0 size of optional header
     102 characteristics
            Executable
            32 bit word machine

从卦中的 32 bit word machine 来看,确实没有开大地址,看样子是受到了 2G 的虚拟地址限制。

不过说实话我真的佩服写这个软件的程序员,在上限 2G 的空间内,能将程序控制在 1.72G 都不崩,把内存压得严严实实,确实🐂👃。

4. 如何开启大地址

开启大地址非常简单,可以用 DnSpy 打开我们的应用程序,然后勾选 Large Address Aware 选项,修改完之后进行保存,截图如下:

记一次 .NET 某零售管理系统 存储不足分析

最后一个问题是开启后他的程序可以吃到 3G 还是 4G 呢?这个取决于是 x64 还是 x86 的操作系统,可以用 vertarget 观察。


0:000:x86> vertarget
Windows 7 Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: WinNt, suite: SingleUserTS
Edition build lab: kernel32.dll version: 6.1.7601.24545 (win7sp1_ldr_escrow.200102-1707)
Debug session time: Mon Nov 27 11:10:18.000 2023 (UTC + 8:00)
System Uptime: 5 days 8:49:46.984
Process Uptime: 1 days 0:50:00.000
  Kernel time: 0 days 0:06:48.000
  User time: 0 days 0:24:11.000

从卦中的 Windows 7 Version 7601 (Service Pack 1) MP (4 procs) Free x64 可知当前是 Windows7 x64 版本,即可以吃到 4G 内存,基本上就能解决这个问题。

三:总结

一般来说这种错误:存储空间不足,无法处理此命令 基本上 98% 都是内存空间不足导致的,只有 2% 的情况真的是 硬盘不足

这个dump最有价值的地方在于没有纠结于 COMException 异常,并且在没有抛出 OutofMemoryException 异常的前提前定位出问题所在。文章来源地址https://www.toymoban.com/news/detail-748876.html

记一次 .NET 某零售管理系统 存储不足分析

到了这里,关于记一次 .NET 某零售管理系统 存储不足分析的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 记一次 .NET某防伪验证系统 崩溃分析

    昨晚给训练营里面的一位朋友分析了一个程序崩溃的故障,因为看小伙子昨天在群里问了一天也没搞定,干脆自己亲自上阵吧,抓取的dump也是我极力推荐的用 procdump 注册 AEDebug 的方式,省去了很多沟通成本。 windbg有一个非常强大的点就是当你双击打开后,会自动帮你切换到

    2024年03月28日
    浏览(64)
  • 记一次 .NET 某券商论坛系统 卡死分析

    前几个月有位朋友找到我,说他们的的web程序没有响应了,而且监控发现线程数特别高,内存也特别大,让我帮忙看一下怎么回事,现在回过头来几经波折,回味价值太浓了。 这个程序内存高,线程高,无响应,尼玛是一个复合态问题,那怎么入手呢?按经验推测,大概率是

    2024年02月05日
    浏览(67)
  • 记一次 .NET 某电力系统 内存暴涨分析

    前些天有位朋友找到我,说他生产上的程序有内存暴涨情况,让我帮忙看下怎么回事,最简单粗暴的方法就是让朋友在内存暴涨的时候抓一个dump下来,看一看大概就知道咋回事了。 这个问题说的再多也不为过,一定要看清楚这个程序是如何个性化发展的,可以使用 !address

    2024年02月08日
    浏览(49)
  • 记一次 .NET某报关系统 非托管泄露分析

    前段时间有位朋友找到我,说他的程序内存会出现暴涨,让我看下是怎么事情?而且还告诉我是在 Linux 环境下,说实话在Linux上分析.NET程序难度会很大,难度大的原因在于Linux上的各种开源工具主要是针对 C/C++, 和 .NET 一毛钱关系都没有,说到底微软在 Linux 上的调试领域支持

    2024年02月14日
    浏览(53)
  • 记一次 .NET某列控连锁系统 崩溃分析

    过年喝了不少酒,脑子不灵光了,停了将近一个月没写博客,今天就当新年开工写一篇吧。 去年年初有位朋友找到我,说他们的系统会偶发性崩溃,在网上也发了不少帖子求助,没找到自己满意的答案,让我看看有没有什么线索,看样子这是一个牛皮藓的问题,既然对方有了

    2024年02月21日
    浏览(57)
  • 记一次 .NET 某工控视觉系统 卡死分析

    前段时间有位朋友找到我,说他们的工业视觉软件僵死了,让我帮忙看下到底是什么情况,哈哈,其实卡死的问题相对好定位,无非就是看主线程栈嘛,然后就是具体问题具体分析,当然难度大小就看运气了。 前几天看一篇文章说现在的 .NET程序员 不需要学习 WinDbg ,理由就

    2024年02月12日
    浏览(51)
  • 记一次 .NET 某旅行社审批系统 崩溃分析

    前些天有位朋友找到我,说他的程序跑着跑着就崩溃了,让我看下怎么回事,其实没怎么回事,抓它的 crash dump 就好,具体怎么抓也是被问到的一个高频问题,这里再补一下链接: [.NET程序崩溃了怎么抓 Dump ? 我总结了三种方案] https://www.cnblogs.com/huangxincheng/p/14811953.html ,采用

    2024年02月09日
    浏览(49)
  • 记一次 .NET某炉膛锅炉检测系统 崩溃分析

    上个月有个朋友在微信上找到我,说他们的软件在客户那边隔几天就要崩溃一次,一直都没有找到原因,让我帮忙看下怎么回事,确实工控类的软件环境复杂难搞,朋友手上有一个崩溃的dump,刚好丢给我来分析一下。 windbg 有一个厉害之处在于双击之后可以帮你自动定位到崩

    2024年04月17日
    浏览(57)
  • 记一次 .NET某道闸收费系统 内存溢出分析

    前些天有位朋友找到我,说他的程序几天内存就要爆一次,不知道咋回事,找不出原因,让我帮忙看一下,这种问题分析dump是最简单粗暴了,拿到dump后接下来就是一顿分析。 程序既然会爆,可能是虚拟地址受限,也可能是系统内存不足,可以用 !address -summary 观察下。 从卦

    2024年01月18日
    浏览(49)
  • 记一次 .NET 某仪器测量系统 CPU爆高分析

    最近也挺奇怪,看到了两起 CPU 爆高的案例,且诱因也是一致的,觉得有一些代表性,合并分享出来帮助大家来避坑吧,闲话不多说,直接上 windbg 分析。 这里要提醒一下,别人说爆高不一定真的就是爆高,我们一定要拿数据说话,可以用 !tp 观察下。 虽然卦中的 CPU 不低但也

    2024年02月08日
    浏览(61)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包