Relanding this.

The Ole unitialization was failing on one of the Vista build-bot.
It is not clear when the Ole initialization is balanced when a CRichEditCtrl is created/destructed.
So I now turn it off explicitly.

This CL makes sure we unregister our Windows window classes when shut-down.
It also balances-out an OLE initialization performed by the CRichEditCTRL.

This is necessary for allowing to reload chrome.dll in a process, which is what
the browser tests will do.

BUG=None
TEST=None

Review URL: http://codereview.chromium.org/101004

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14649 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 5 insertions, 2 deletions

diff --git a/chrome/browser/process_singleton_win.cc b/chrome/browser/process_singleton_win.cc
index 99d2d5f..c34a4d1 100644
--- a/chrome/browser/process_singleton_win.cc
+++ b/chrome/browser/process_singleton_win.cc
@@ -45,8 +45,10 @@ ProcessSingleton::ProcessSingleton(const FilePath& user_data_dir)
 }
 
 ProcessSingleton::~ProcessSingleton() {
-  if (window_)
+  if (window_) {
     DestroyWindow(window_);
+    UnregisterClass(chrome::kMessageWindowClass, GetModuleHandle(NULL));
+  }
 }
 
 bool ProcessSingleton::NotifyOtherProcess() {
@@ -142,7 +144,8 @@ void ProcessSingleton::Create() {
   wc.lpfnWndProc = ProcessSingleton::WndProcStatic;
   wc.hInstance = hinst;
   wc.lpszClassName = chrome::kMessageWindowClass;
-  RegisterClassEx(&wc);
+  ATOM clazz = RegisterClassEx(&wc);
+  DCHECK(clazz);
 
   std::wstring user_data_dir;
   PathService::Get(chrome::DIR_USER_DATA, &user_data_dir);