Question

有时，我们会在其中一个IIS进程中获得@RunWith(Enclosed.class) public class SampleTest { @RunWith(Parameterized.class) public static class WhenPassingNonNull { @Parameters public static Collection<object[]> methodParams() { List<Object[]> params = new ArrayList<Object[]>(); /* arg, errorString */ params.add(new Object[] {"arg1", "result1"}); params.add(new Object[] {"arg3", "result3"}); } public final String arg; public final String actualResult; public SampleTest(String arg, String actualResult) { this.arg = arg; this.actualResult = actualResult; } @Test public void sampleTest() { String actualResult = ClassUnderTest.methodAndWait(arg); assertEquals(expectedResult, actualResult); } } @RunWith(JUnit4.class) public static class WhenPassingNull { @Test public void shouldThrowNullPointerException() { try { ClassUnderTest.methodAndWait(null); fail(); } catch (NullPointerException ex) { assertTrue(ex.getMessage().contains(ERROR_STRING1)); } } } }。我试图分析转储，但无法得出具体的结论。我也试过调查MS修补程序，发现类似的问题和解决方案，但不确定它是否相关：link

以下是WinDbg中OutOfMemoryException命令的输出：

!analyze -v

评论要求提供的其他信息：

!analyze -v

[...]

CoInitialize failed 80010106
CoInitialize failed 80010106
CoInitialize failed 80010106
GetPageUrlData failed, server returned HTTP status 404
URL requested: http://watson.microsoft.com/StageOne/w3wp_exe/7_5_7601_17514/4ce7a5f8/unknown/0_0_0_0/bbbbbbb4/80000007/00000000.htm?Retriage=1

FAULTING_IP: 
+75d2faf02afdbf0
00000000 ??              ???

EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 00000000
   ExceptionCode: 80000007 (Wake debugger)
  ExceptionFlags: 00000000
NumberParameters: 0

BUGCHECK_STR:  80000007

PROCESS_NAME:  w3wp.exe

ERROR_CODE: (NTSTATUS) 0x80000007 - {Kernel Debugger Awakened}  the system debugger was awakened by an interrupt.

EXCEPTION_CODE: (HRESULT) 0x80000007 (2147483655) - Operation aborted

MOD_LIST: *** ERROR: Could not build analysis XML

NTGLOBALFLAG:  0

APPLICATION_VERIFIER_FLAGS:  0

MANAGED_STACK: !dumpstack -EE
OS Thread Id: 0x2364 (0)
Current frame: 
ChildEBP RetAddr  Caller, Callee

DERIVED_WAIT_CHAIN:  

Dl Eid Cid     WaitType
-- --- ------- --------------------------
   0   370.2364 Event                  

WAIT_CHAIN_COMMAND:  ~0s;k;;

BLOCKING_THREAD:  00002364

DEFAULT_BUCKET_ID:  APPLICATION_HANG_BlockedOn_EventHandle

PRIMARY_PROBLEM_CLASS:  APPLICATION_HANG_BlockedOn_EventHandle

LAST_CONTROL_TRANSFER:  from 758e149d to 778df8c1

FAULTING_THREAD:  00000000

STACK_TEXT:  
002efb8c 758e149d 000001d4 00000000 00000000 ntdll!ZwWaitForSingleObject+0x15
002efbf8 75c71194 000001d4 ffffffff 00000000 KERNELBASE!WaitForSingleObjectEx+0x98
002efc10 75c71148 000001d4 ffffffff 00000000 kernel32!WaitForSingleObjectExImplementation+0x75
002efc24 7470765a 000001d4 ffffffff 747057c1 kernel32!WaitForSingleObject+0x12
002efc30 747057c1 00000000 74706f84 00a21320 w3wphost!WP_IPM::WaitForShutdown+0xb
002efc38 74706f84 00a21320 00a215d0 002efd58 w3wphost!W3WP_HOST::WaitForShutdown+0x11
002efc48 00a22bdb 002efc68 00a25708 00000001 w3wphost!AppHostInitialize+0x11e
002efd58 00a23584 0000000f 00702828 00703b48 w3wp!wmain+0x373
002efd9c 75c733aa fffde000 002efde8 778f9ed2 w3wp!_initterm_e+0x163
002efda8 778f9ed2 fffde000 71b16c75 00000000 kernel32!BaseThreadInitThunk+0xe
002efde8 778f9ea5 00a236b5 fffde000 ffffffff ntdll!__RtlUserThreadStart+0x70
002efe00 00000000 00a236b5 fffde000 00000000 ntdll!_RtlUserThreadStart+0x1b


FOLLOWUP_IP: 
w3wphost!WP_IPM::WaitForShutdown+b
7470765a f60520d0707403  test    byte ptr [w3wphost!g_dwDebugFlags (7470d020)],3

SYMBOL_STACK_INDEX:  4

SYMBOL_NAME:  w3wphost!WP_IPM::WaitForShutdown+b

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: w3wphost

IMAGE_NAME:  w3wphost.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  4ce7a5d0

STACK_COMMAND:  ~0s ; kb

BUCKET_ID:  80000007_w3wphost!WP_IPM::WaitForShutdown+b

FAILURE_BUCKET_ID:  APPLICATION_HANG_BlockedOn_EventHandle_80000007_w3wphost.dll!WP_IPM::WaitForShutdown

WATSON_STAGEONE_URL:  http://watson.microsoft.com/StageOne/w3wp_exe/7_5_7601_17514/4ce7a5f8/unknown/0_0_0_0/bbbbbbb4/80000007/00000000.htm?Retriage=1

Followup: MachineOwner

Answer 1

根据!vmstat的输出，你的内存不足。有一些温和的地址空间碎片，但你只有大约350MB的可用内存，所以你真的在接近地址空间限制。最大的空闲块只有6MB，CLR分配的虚拟内存段至少为16MB。

您的GC堆总大小仅为470MB（请参阅!eeheap -gc输出的最后一行），这意味着您的进程中还有其他内容使用了地址空间。即，您具有> 500MB的图像（DLL）和> 3GB的分类为“私有”的存储器。这可能是一堆不同的东西;例如，它可以是非托管堆分配。

您可以尝试通过运行!heap -s -h 0来进一步放大太空猪，以查看您的进程中是否有大量非托管堆。我建议，一旦你有一个方向（是否是一个非托管堆泄漏？还有其他什么？）用你的发现提出另一个问题。根据您目前发布的信息，我们可以得出结论，这可能与您的应用程序的托管部分正在做的事情无关。您的应用程序中是否有大型非托管组件？有一些技术可用于分析非托管内存泄漏，例如UMDH或ETW堆分配跟踪。

最后一条评论：为什么在32个处理器的系统上运行32位应用程序？看起来像一个服务器系统，我打赌你有超过4GB的物理内存。如果它完全由您控制，请尝试移动到64位。

在IIS中赢取dbg Dump OOM异常

1 个答案: