Sign Up

Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.

Have an account? Sign In

Have an account? Sign In Now

Sign In

Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.

Sign Up Here

Forgot Password?

Don't have account, Sign Up Here

Forgot Password

Lost your password? Please enter your email address. You will receive a link and will create a new password via email.

Have an account? Sign In Now

You must login to ask a question.

Forgot Password?

Need An Account, Sign Up Here

Please briefly explain why you feel this question should be reported.

Please briefly explain why you feel this answer should be reported.

Please briefly explain why you feel this user should be reported.

Sign InSign Up

The Archive Base

The Archive Base Logo The Archive Base Logo

The Archive Base Navigation

  • Home
  • SEARCH
  • About Us
  • Blog
  • Contact Us
Search
Ask A Question

Mobile menu

Close
Ask a Question
  • Home
  • Add group
  • Groups page
  • Feed
  • User Profile
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Buy Points
  • Users
  • Help
  • Buy Theme
  • SEARCH
Home/ Questions/Q 9140373
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Editorial Team
Asked: June 17, 20262026-06-17T09:30:29+00:00 2026-06-17T09:30:29+00:00

Is it possible to crash a regular user-mode process on Windows-7 without getting the

  • 0

Is it possible to crash a regular user-mode process on Windows-7 without getting the Windows Error Reporting (WER) dialog? (When and if WER is normally enabled and no specific flags are applied.)

Note: I’m not interested in disabling WER, I’m interested in crash scenarios where WER isn’t launched although it should and Windows “silently” terminates an app.

On Windows XP, it is pretty trivial to write a C or C++ application (in user mode) that messes up its own address space in such a way that when an Access Violation (or other unhandled Win32 Exception) is finally raised, Windows XP will just silently terminate the process without informing the user at all:

...
void stackbreaker() {
    printf("%s\n", __FUNCTION__);
    // global/static buffer
    static char buf[128] = "In a hole in the ground there lived a hobbit. And it burrowed through your stack. It even built a round door into you function.";
    // Get address on the stack
    char local;
    char* stack = &local;
    // nuke the stack:
    memcpy(stack - 64, buf, sizeof(buf));
    // Kaboom. No user defined unhandled exception filter will be called. Stack nuked.
    // Process will terminate silently on Windows XP.
    // But on Windows-7 you still get the WER dialog.
}
...

Calling the above function in a simple C++ project (in release mode — watch out for those compiler optimizations when testing — and not run under the debugger) will:

  • Silently terminate the process, under XP.
  • Display the WER crash dialog under Windows-7.
  • Aside: In no circumstance will it call your own unhandled exception filter, even if you set one via SetUnhandledExceptionFilter

What I am wondering now is whether – under Windows 7 – the WER mechanism has been implemented in a way that I always get an error dialog for a crash[a] in my application, or whether there exist process corruption scenarios even in Windows 7, that will prevent the WER dialog from popping up?


I’ll add a bit of the reading up I did:

In the book Windows via C/C++ (5th ed by Richter, Nasarre) they describe what happens in a “Faulting Process” (p 711):

  1. Exception filters.
  2. …
  3. …
  4. kernel detects unhandled exception
  5. blocking ALPC call to Wer Service
  6. WER reporting kicks in.
  7. …

Now, they point here is that Win7 does this differently than Windows XP (to quote this book p. 710:)

… Starting with Windows Vista, the UnhandledExceptionFilter function no longer sends an error report to MS’ servers. Instead. The kernel detects that the exception is not handled by the user-mode thread (Step 4)…

So this would imply, that there is no way at all for a process to “crash” — in Vista and above — in a way that prevents WER kicking in. I’m trying to either confirm or refute this.


[a]: Obviously, a process can easily be “killed” without any trace by calling one of the various *exit or terminate* functions. The question is, if you can rule out such a termination reason, (how) is it possible to “crash” a user-mode process on Win7 in a way that would prevent the WER dialog from being displayed.

  • 1 1 Answer
  • 0 Views
  • 0 Followers
  • 0
Share
  • Facebook
  • Report

Leave an answer
Cancel reply

You must login to add an answer.

Forgot Password?

Need An Account, Sign Up Here

1 Answer

  • Voted
  • Oldest
  • Recent
  • Random
  1. Editorial Team
    Editorial Team
    2026-06-17T09:30:30+00:00Added an answer on June 17, 2026 at 9:30 am

    I took a look at my edition of Windows Internals, but it doesn’t have a whole lot to say on the subject. In earlier versions, the windows error reporting routine took place in the context of the crashing thread. This means that if the stack is trashed (as in your example), it might not be able to run.

    In Vista and later, it runs externally to the crashing thread. In addition, the kernel itself is responsible for notifying WER when a process crashes (through an advanced local procedure call).

    According to Windows Internals, these changes fix the vanishing process problem. I can only take their word for that. Obviously, if the WER service is itself damaged (or stopped), you’ll still get silent crashes.

    EDIT

    From Windows Internals, 5th Edition, page 122:

    Until Windows Vista, all the [WER] operations we’ve described had to occur within the crashing thread’s context… In certain types of crashes … the unhandled exception filter itself crashed. This “silent process death” was not logged anywhere. … Windows Vista and later versions improved the WER mechanism by performing this work externally from the crashed thread, if the unhandled exception filter itself crashes.

    Page 124:

    …all Windows processes now have an error port that is actually an ALPC port object registered by the WER service. The kernel … will use this port to send a message to the WER service, which will then analyze the crashing process. … This solves all the problems of silent process death…

    • 0
    • Reply
    • Share
      Share
      • Share on Facebook
      • Share on Twitter
      • Share on LinkedIn
      • Share on WhatsApp
      • Report

Sidebar

Related Questions

Possible Duplicate: presentViewController: crash on iOS 6 (AutoLayout) I'm getting this error when clicking
Possible Duplicate: Serializable crash error when loading web broser from my application below a
Possible Duplicate: Objective C for Windows iPhone development on Windows Is there any way
Possible Duplicate: Crash on ListView.removeFooterView(View) How is it possible to get a null pointer
Possible Duplicate: presentViewController: crash on iOS <6 (AutoLayout) How to use NSLayoutConstraint in iOS
Possible Duplicate: How to prevent crash in C++ typedef struct { int val; }
Possible Duplicate: C/C++ Char Pointer Crash char *p = atl; char c; c =
Possible Duplicate: Storyboard Could not instantiate class named UIStoryboardUnwindSegueTemplate crash As with this question
Possible Duplicate: Spawn a background process in Ruby Spent a couple days poking at
Possible Duplicate: App crash on 4.0 but not on 5.0 In My iPhone App

Explore

  • Home
  • Add group
  • Groups page
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Users
  • Help
  • SEARCH

Footer

© 2021 The Archive Base. All Rights Reserved
With Love by The Archive Base

Insert/edit link

Enter the destination URL

Or link to existing content

    No search term specified. Showing recent items. Search or use up and down arrow keys to select an item.