Windows Shutdown

I found that all Forms require this Sub, if any do not have it then it seems it will not do the job.

Hmm, if that was the case then my simple one form test would have prevented shutdown, but it didn't.

Hi

Presumably the Forms in my app (there are only 2 of them) must each implicitly send a False/zero when polled by WM_QUERYENDSESSION? As I am using this for the first time, I am not able to be more specific. All I know is that when I placed that Sub in Form1 alone, the same shutdown sequence occurred as before. I tried adding it to Form2m with little expectation, and thereafter, both instances of the app did not invoke the wrath of Windows Shutdown anymore.

I may retry with only Form1 having that Sub, but later maybe as I am fed up with shutting down/restarting the whole shebang so much.

I have no idea as to what apps use to dictate the response they will provide when polled. For example, an unsaved text in Notepad will trigger the False/zero response but as to the code behind, I suppose it must have a flag in code to gold current changed content - or something similar. However, my app never does have unsaved changes at rime of Windows Shutdown so I can't chase that line to try a 'fix'.

Anyway, thanks for your input.

When asked about one Form or all Forms for the code snippet I posted, Copilot says this:

This is a really interesting scenario—thanks for laying it out so clearly. What you’re bumping into might come down to how Windows handles WM_QUERYENDSESSION across running forms in a WinForms app. A couple of factors could explain why applying that override only in Form1 isn’t enough:

🧩 Key Factors That Might Be in Play

• Form2 Might Still Be Active or Displayed During Shutdown
  • If Form2 is open or hasn’t been disposed properly when the system sends WM_QUERYENDSESSION, Windows will check each top-level window's response.
  • If Form2’s window doesn't explicitly respond with TRUE (m.Result = CType(1, IntPtr)), Windows assumes the app might be blocking shutdown.
  Windows Treats Each Form Separately for Shutdown Confirmation Unlike closing an app manually, during system shutdown Windows queries each top-level window independently via WM_QUERYENDSESSION.

    If any form fails to respond correctly—or defers to the base implementation, which might **not** respond with `TRUE`—you’ll get the “preventing shutdown” dialog.
  
    **App Structure and Message Routing May Vary**
  
       In some setups, especially with custom application loops or message routing, not all forms may receive this message unless explicitly hooked.
  
          Others who say Form1 alone is enough might have Form2 either minimized, hidden, or non-blocking during shutdown, causing the OS to disregard it.
  

🔧 Possible Solutions

Ensure All Active Forms Override WndProc for WM_QUERYENDSESSION

Best practice: override WndProc for every top-level form that might still be open when shutdown occurs.

  Alternatively, centralize the message handling using `Application.AddMessageFilter`, though this adds complexity.
  
  **Close Secondary Forms Before Shutdown (if applicable)**
  
     If Form2 is only a helper or dialog, make sure it’s disposed or closed programmatically when Form1 finishes or when the user logs off.
     
     **Log Which Forms Receive the Message**
     
        Add logging in the override to see which forms are hit with `WM_QUERYENDSESSION`. That might confirm that Form2 is actively receiving it.
        

🧠 Fun Side Note

Even though your override looks totally correct, Windows doesn’t treat the app as a monolithic window—it queries what’s visible and top-level at the time of shutdown. So even a tiny form that’s lurking in the background can trigger that “preventing shutdown” warning if it doesn’t play nice.This is a really interesting scenario—thanks for laying it out so clearly. What you’re bumping into might come down to how Windows handles WM_QUERYENDSESSION across running forms in a WinForms app. A couple of factors could explain why applying that override only in Form1 isn’t enough:

🧩 Key Factors That Might Be in Play

Form2 Might Still Be Active or Displayed During Shutdown

If Form2 is open or hasn’t been disposed properly when the system sends WM_QUERYENDSESSION, Windows will check each top-level window's response.

  If Form2’s window doesn't explicitly respond with `TRUE` (`m.Result = CType(1, IntPtr)`), Windows assumes the app might be blocking shutdown.
  
  **Windows Treats Each Form Separately for Shutdown Confirmation**
  
     Unlike closing an app manually, during system shutdown Windows queries **each top-level window** independently via `WM_QUERYENDSESSION`.
     
        If any form fails to respond correctly—or defers to the base implementation, which might **not** respond with `TRUE`—you’ll get the “preventing shutdown” dialog.
        
        **App Structure and Message Routing May Vary**
        
           In some setups, especially with custom application loops or message routing, not all forms may receive this message unless explicitly hooked.
           
              Others who say Form1 alone is enough might have Form2 either minimized, hidden, or non-blocking during shutdown, causing the OS to disregard it.
              

🔧 Possible Solutions

Ensure All Active Forms Override WndProc for WM_QUERYENDSESSION

Best practice: override WndProc for every top-level form that might still be open when shutdown occurs.

  Alternatively, centralize the message handling using `Application.AddMessageFilter`, though this adds complexity.
  
  **Close Secondary Forms Before Shutdown (if applicable)**
  
     If Form2 is only a helper or dialog, make sure it’s disposed or closed programmatically when Form1 finishes or when the user logs off.
     
     **Log Which Forms Receive the Message**
     
        Add logging in the override to see which forms are hit with `WM_QUERYENDSESSION`. That might confirm that Form2 is actively receiving it.
        

🧠 Fun Side Note

Even though your override looks totally correct, Windows doesn’t treat the app as a monolithic window—it queries what’s visible and top-level at the time of shutdown. So even a tiny form that’s lurking in the background can trigger that “preventing shutdown” warning if it doesn’t play nice.

All of this is AI blather. The real question is whether the Windows Forms implementation defaults to responding TRUE to WM_QUERYENDSESSION if no other code is provided that prevents closing the form.

From the docs for the WM_QUERYENDSESSION message - "Applications should respect the user's intentions and return TRUE. By default, the DefWindowProc function returns TRUE for this message.

If shutting down would corrupt the system or media that is being burned, the application can return FALSE. However, it is good practice to respect the user's actions."

Don't you think that if overriding WndProc was mandatory to handle WM_QUERYENDSESSION Microsoft would document it somewhere? And if it was mandatory every Windows Forms application that doesn't do it would prevent shutdown and forums would be filled with questions about this mystery.

When 'AI blather.' is all you have then 'AI blather.' it is, Apart from yourself, I had no responses when seeking help other than 'AI blather.'