Fix Windows logoff race.

chrome/browser/lifetime/application_lifetime.cc

Index: chrome/browser/lifetime/application_lifetime.cc
diff --git a/chrome/browser/lifetime/application_lifetime.cc b/chrome/browser/lifetime/application_lifetime.cc
index 7e377a83cf581c26467528f1d155d0af4b054b8c..21b9e3bda36e273f8b1bb21e662c098a55279e8c 100644
--- a/chrome/browser/lifetime/application_lifetime.cc
+++ b/chrome/browser/lifetime/application_lifetime.cc
@@ -12,6 +12,8 @@
 #include "base/memory/scoped_ptr.h"
 #include "base/message_loop/message_loop.h"
 #include "base/prefs/pref_service.h"
+#include "base/process/kill.h"
+#include "base/process/process.h"
 #include "build/build_config.h"
 #include "chrome/browser/browser_process.h"
 #include "chrome/browser/browser_process_platform_part.h"
@@ -276,6 +278,15 @@ void SessionEnding() {
   // Write important data first.
   g_browser_process->EndSession();
 
+#if defined(OS_WIN)
+  base::win::SetShouldCrashOnProcessDetach(false);
+
+  // On Windows 7 and later, the system will consider the process ripe for
+  // termination as soon as it hides or destroys its windows. Since any
+  // execution past that point will be non-deterministically cut short, we
+  // might as well put ourselves out of that misery deterministically.
+  base::KillProcess(base::Process::Current().handle(), 0, false);

[Shrikant Kelkar, 2014/07/07 20:02:58]

Instead of killing here, can we let the process continue and cover as much
mileage as possible? CloseAllBrowsers() is tangled with App closing and multiple
hacks for ASH/Metro close.

[Sigurður Ásgeirsson, 2014/07/07 20:17:18]

I would really rather not do that, as this gives the false impression that
useful work can be achieved here, which in turn makes it a certainty that this
will regress again. We've been broken on Windows logoff for two years :(, and
this code should never run exception as consequence of a WM_ENDSESSION message.

Ugh - is this what you're worried about:
[https://code.google.com/p/chromium/codesearch#chromium/src/win8/metro_driver/chrome_app_view.cc&q=WM_ENDSESSION&sq=package:chromium&type=cs&l=625]?
If this doesn't tolerate a TerminateProcess, then it needs to be rerouted to use
another message or some such.

The WM_ENDSESSION path is VERY special, as here Windows is going to kill you
very shortly after the browser windows are closed.
There's also a strict time limit in effect. If we dally, then Windows will fling
up a complaint saying something like "Chrome's preventing logoff/shutdown" and
give the user the option of killing it anyway.

Can you please test whether this causes trouble on Win8 (I don't have hardware
to test this), and if so, I can remove the TerminateProcess in the short term.
This MUST however be disentangled by using something else than WM_ENDSESSION on
Win8.

+#else
   CloseAllBrowsers();
 
   // Send out notification. This is used during testing so that the test harness
@@ -285,11 +296,9 @@ void SessionEnding() {
       content::NotificationService::AllSources(),
       content::NotificationService::NoDetails());
 
-#if defined(OS_WIN)
-  base::win::SetShouldCrashOnProcessDetach(false);
-#endif
   // This will end by terminating the process.
   content::ImmediateShutdownAndExitProcess();
+#endif  // defined(OS_WIN)
 }
 
 void IncrementKeepAliveCount() {