Full stack trace: 

[0502/164124:FATAL:message_window.cc(76)] Check failed: CalledOnValidThread().
Backtrace:
        base::debug::StackTrace::StackTrace [0x000000014151DE91+33] (c:\users\an
dre_000\chromium\src\base\debug\stack_trace_win.cc:215)
        logging::LogMessage::~LogMessage [0x00000001413DC2E1+65] (c:\users\andre
_000\chromium\src\base\logging.cc:520)
        base::win::MessageWindow::~MessageWindow [0x000000014145D93E+206] (c:\us
ers\andre_000\chromium\src\base\win\message_window.cc:78)
        base::win::MessageWindow::`scalar deleting destructor' [0x00000001401E96
07+23]
        std::default_delete<base::win::MessageWindow>::operator() [0x00000001401
E93C9+57] (c:\users\andre_000\depot_tools\win_toolchain\vs_files\95ddda401ec5678
f15eeed01d2bee08fcbc5ee97\vc\include\memory:1195)
        std::unique_ptr<base::win::MessageWindow,std::default_delete<base::win::
MessageWindow> >::~unique_ptr<base::win::MessageWindow,std::default_delete<base:
:win::MessageWindow> > [0x00000001401E81E1+65] (c:\users\andre_000\depot_tools\w
in_toolchain\vs_files\95ddda401ec5678f15eeed01d2bee08fcbc5ee97\vc\include\memory
:1398)
        device::DeviceMonitorMessageWindow::~DeviceMonitorMessageWindow [0x00000
001401E8265+53] (c:\users\andre_000\chromium\src\device\core\device_monitor_win.
cc:80)
        device::DeviceMonitorMessageWindow::`scalar deleting destructor' [0x0000
0001401E9567+23]
        base::DeletePointer<device::DeviceMonitorMessageWindow> [0x00000001401E2
4A4+52] (c:\users\andre_000\chromium\src\base\bind_helpers.h:627)
        base::internal::RunnableAdapter<void (__cdecl*)(device::DeviceMonitorMes
sageWindow * __ptr64)>::Run<device::DeviceMonitorMessageWindow * __ptr64> [0x000
00001401E2722+34] (c:\users\andre_000\chromium\src\base\bind_internal.h:160)
        base::internal::InvokeHelper<0,void,base::internal::RunnableAdapter<void
 (__cdecl*)(device::DeviceMonitorMessageWindow * __ptr64)> >::MakeItSo<device::D
eviceMonitorMessageWindow * __ptr64> [0x00000001401E24F5+37] (c:\users\andre_000
\chromium\src\base\bind_internal.h:322)
        base::internal::Invoker<base::IndexSequence<0>,base::internal::BindState
<base::internal::RunnableAdapter<void (__cdecl*)(device::DeviceMonitorMessageWin
dow * __ptr64)>,void __cdecl(device::DeviceMonitorMessageWindow * __ptr64),base:
:internal::UnretainedWr [0x00000001401EAB64+68] (c:\users\andre_000\chromium\src
\base\bind_internal.h:375)
        base::Callback<void __cdecl(void),1>::Run [0x00000001401390A8+40] (c:\us
ers\andre_000\chromium\src\base\callback.h:398)
        base::AtExitManager::ProcessCallbacksNow [0x00000001413DFD8E+302] (c:\us
ers\andre_000\chromium\src\base\at_exit.cc:83)
        base::AtExitManager::~AtExitManager [0x00000001413DFA1F+351] (c:\users\a
ndre_000\chromium\src\base\at_exit.cc:42)
        main [0x000000014012B314+132] (c:\users\andre_000\chromium\src\tools\bat
tor_agent\battor_agent_bin.cc:310)
        invoke_main [0x00000001417574A4+52] (f:\dd\vctools\crt\vcstartup\src\sta
rtup\exe_common.inl:65)
        __scrt_common_main_seh [0x000000014175735E+302] (f:\dd\vctools\crt\vcsta
rtup\src\startup\exe_common.inl:255)
        __scrt_common_main [0x000000014175721E+14] (f:\dd\vctools\crt\vcstartup\
src\startup\exe_common.inl:300)
        mainCRTStartup [0x00000001417574C9+9] (f:\dd\vctools\crt\vcstartup\src\s
tartup\exe_main.cpp:17)
        BaseThreadInitThunk [0x00007FFA3AF316AD+13]
        RtlUserThreadStart [0x00007FFA3B0C4409+29]

So it looks like what's happening is that, on Windows, the SerialIoHandler uses a singleton called the DeviceMonitorWin in order to keep track of devices that are added and removed. We use the SerialIoHandler to query for the list of attached serial devices. 

The problem is that this singleton registers with the AtExitManager to say "delete me when the AtExitManager goes out of scope". However, when the SerialIoHandler is created, it's on the IO thread. The AtExitManager is on the main thread. The DeviceMonitorWin asserts that its deletion happens on the same thread as its creation... which obviously doesn't happen. This results in a crash.

rockot@ helped me debug what was going on here. It looks like there's an assumption in Chrome that the main() thread is also the UI thread. However, within the battor_agent_bin, we start up our own UI thread and pass it into the BattOrAgent. 

A few levels of piping later, the SerialDeviceEnumerator uses this same UI thread to create all of this MessageWindow stuff.

Later on, when the main() goes to exit, the AtExitManager goes out of scope and tries to delete the MessageWindow (through a few layers). It assumes it's still on the same UI thread, but because we're running a separate UI thread, it's actually on a different one, and the crash ensues.

Some options worth investigating:

  1) We use the main() thread as the UI thread. If possible, this is probably the best choice.
  2) We make the AtExitManager wrap around our own UI thread startup/shutdown rather than the main() thread.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e0d672480e8c352a0f7ab4d67a87d58bb543d943

commit e0d672480e8c352a0f7ab4d67a87d58bb543d943
Author: charliea <charliea@chromium.org>
Date: Wed May 04 19:25:50 2016

[battor agent] Makes the main() thread also be the UI thread

This requires changes to the threading model because, before, we were
allowed to block the main() thread until each of the tracing commands
returned. Now that we're using the main() thread as the UI thread,
there's an expectation that it won't block while the command is
executing (because at some point the IO thread might delegate back to
the IO thread for a task, resulting in a deadlock).

This fixes a bug on Windows where a MessageWindow that was created on
the UI thread was check failing on exit because it was expecting to be
destroyed on the same thread. This happened every time that the agent
shut down on Windows.

BUG= 603309 

Review-Url: https://codereview.chromium.org/1949673003
Cr-Commit-Position: refs/heads/master@{#391599}

[modify] https://crrev.com/e0d672480e8c352a0f7ab4d67a87d58bb543d943/tools/battor_agent/battor_agent_bin.cc

I believe this issue is fixed so I am changing its status. Please reopen if it is not.