Why is my crash dump file filled with 0xAAAAAAAA?


A customer was studying a minidump collected by Windows Error Reporting. The minidump includes the contents of the stack, but the contents are randomly filled with 0xAAAAAAAA.

00f3ac5c  00f3d1c0
00f3ac60  592ccae2 contoso!AppWndProc+0x1c5b
00f3ac64  aaaaaaaa
00f3ac68  aaaaaaaa
00f3ac6c  aaaaaaaa
00f3ac70  aaaaaaaa
00f3ac74  00000000
00f3ac78  00000000
00f3ac7c  58e75a46 contoso!WndProcGeneric
00f3ac80  504e7fea cohelp!allyourbuttons+0x5aba
00f3ac84  aaaaaaaa
00f3ac88  aaaaaaaa
00f3ac8c  00000000
00f3ac90  00000000
00f3ac94  0ee26838
00f3ac98  00000000
00f3ac9c  aaaaaaaa
00f3aca0  58ec7405 contoso!GetBlockBeforeCapture+0x2e
00f3aca4  0ee26838
00f3aca8  0fd6db10
00f3acac  00000000
00f3acb0  aaaaaaaa
00f3acb4  00f3ad04
00f3acb8  58ec732f contoso!FindDrawingFromGraphicId+0x136
00f3acbc  aaaaaaaa
00f3acc0  00000000
00f3acc4  00000000
00f3acc8  00000000
00f3accc  00000000
00f3acd0  aaaaaaaa
00f3acd4  aaaaaaaa
00f3acd8  aaaaaaaa

What's going on here?

What's going on is that the minidump has been filtered. The customer missed this message from the debugger that was printed at the top of the debug session:

User Mini Triage Dump File: Only registers, stack and portions of memory are available

The user dump currently examined is a triage dump. Consequently, only a subset of debugger functionality will be available. If needed, please collect a minidump or a heap dump.

  • To create a mini user dump use the command: .dump /m <filename>
  • To create a full user dump use the command: .dump /ma <filename>

Triage dumps have certain values on the stack and in the register contexts overwritten with pattern 0xAAAAAAAA. If you see this value

  1. the original value was not NULL
  2. the original value was not a direct pointer to a loaded or unloaded image
  3. the original value did not point to an object whose VFT points to a loaded or unloaded image (indirect pointer)

  4. the original value did not point to the stack itself or any memory area added to the dump (TEB, PEB, memory for CLR stackwalk or exceptions, etc.)

  5. the original value was not a valid handle value

After receiving this explanation, the customer was still a bit dubious. "A lot of function parameters in the dump are being given as 0xAAAAAAAA, which suggests that they have been filtered out. But I thought constant strings and plain integers should still be on the stack. Does the fact that I don't see them mean that they were corrupted?"

If you look at the information banner printed by the debugger, you can see that plain integers are not on the list of things exempt from filtering. You might still see an integer if it happens to match a value that is exempt from filtering, such as if it happens to be zero or match a valid handle.

As for constant strings, it depends on how the constant string is stored. If it's a literal string embedded in a module, then it would be exempt from filtering according to rule 2. But if the string were copied to the heap or to the stack, then that would make it subject to filtering.

Comments (13)
  1. Ray Koopa says:

    And I thought it was an outcry from a failed application.

    1. Jason says:

      "Well, it wouldn't have outputted 0xAAAAAAAA while it was crashing."

      "Maybe the debugger was taking dictation?"

  2. Damien says:

    "No, it’s just that the original data was scrubbed out." isn't usually an answer to a "Why" question, and certainly not the one posed in the title

    1. Eddie Lotter says:

      Unless I completely misunderstood your post, it looks like a strawman argument. Raymond doesn't answer "No" to a "Why" question.

      1. parkrrrr says:

        He does, sort of. It's the tl;dr subhead for this post on the main page. You can't see it from here.

        1. Rick C says:

          Likely the subhead was an answer to the question asked in the article, "Does the fact that I don't see them mean that they were corrupted?"

          1. Ivan K says:

            With the all-caps AAys I thought it might be the answer to "Does Microsoft also agree that my feature is the coolest ever and think I deserve a bonus despite the crashes"? (Fonzie / Happy Days reference)

    2. Josh B says:

      Raymond answered fine. "Why is there so much 0xAAAAAAAA in my dump?" "Because the data was filtered out."

      Now you have a follow-up question: "Why is the data filtered out?" That's not answered, perhaps because it should be blindingly obvious to anyone who pays attention to attitudes toward Microsoft: Privacy advocates, businesses, and general haters would foam at the mouth that Microsoft was transmitting confidential information and spying on their customers, even more so than they already do. It's a way of appeasing the public, and removing any potential temptation from its employees.

  3. Matteo Italia says:

    I still don't get why these values are filtered in this particular kind of minidump - to keep the size down? For privacy? Something else?

    1. DWalker07 says:

      Exactly. WHY are these values filtered out? So we won't waste time looking at them, perhaps? Is that the reason?

  4. Yukkuri says:

    Why is any data being scrubbed?

    1. Yukkuri says:

      would this be the reason why?

      http://www.google.com/patents/US8645763

      "To reduce the risk of user-specific personal being included in the memory dump, portions of memory that contain data characteristic of personal data are “poisoned” by overwriting the data values with overwrite values."

    2. smf says:

      "Why is any data being scrubbed?"

      Triage in medicine isn't about diagnosing everything wrong with the patient, it's about figuring out the order to deal with the patients to get the best overall outcome.

      My guess is that a triage dump is smaller to transmit & store plus it's probably easier to look at.

Comments are closed.

Skip to main content