Actually assign to alexclark since this check was recently added here 
https://chromium-review.googlesource.com/c/chromium/src/+/1320329

Just checked, does not crash on login screen. Rather crashes when opening a SMB share dialog. Below are details.

Error message:
Check Failed: MessageLoop::TYPE_IO == loop->type() (3 vs. 1)

Repro steps:
1. Settings -> Download -> Network File Shares
2. Click "Add File Share" button

Expected Result:
Add file share dialog to pop up.

Actual Result:
DCHECK error

For future reference could you please include a callstack when you report DCHECKS?  There should be one generated.

I was able to reproduce this, thanks for the instructions.

[87965:87965:1119/122743.783240:FATAL:message_loop_current.cc(212)] Check failed: loop->IsType(MessageLoop::TYPE_IO). 
#0 0x7f4ac9ef22bd base::debug::StackTrace::StackTrace()
#1 0x7f4ac9bed60a base::debug::StackTrace::StackTrace()
#2 0x7f4ac9c594fe logging::LogMessage::~LogMessage()
#3 0x7f4ac9c7be96 base::MessageLoopCurrentForIO::Get()
#4 0x7f4ac78fee85 net::UDPSocketPosix::RecvFrom()
#5 0x7f4ac751a458 net::UDPServerSocket::RecvFrom()
#6 0x7f4ac7a64475 net::MDnsConnection::SocketHandler::DoLoop()
#7 0x7f4ac7a64335 net::MDnsConnection::SocketHandler::Start()
#8 0x7f4ac7a65b52 net::MDnsConnection::Init()
#9 0x7f4ac7a66c4c net::MDnsClientImpl::Core::Init()
#10 0x7f4ac7a6b5b1 net::MDnsClientImpl::StartListening()
#11 0x55566e962d4e chromeos::smb_client::MDnsHostLocator::StartListening()
#12 0x55566e962dcc chromeos::smb_client::MDnsHostLocator::FindHosts()
#13 0x55566e96d8ec chromeos::smb_client::NetworkScanner::FindHostsInNetwork()
#14 0x55566e997d13 chromeos::smb_client::SmbShareFinder::GatherSharesInNetwork()
#15 0x55566e98d98f chromeos::smb_client::SmbService::GatherSharesInNetwork()
#16 0x5556748b8d28 chromeos::smb_dialog::SmbHandler::HandleStartDiscovery()
#17 0x55566c8f6180 _ZN4base8internal13FunctorTraitsIMN10extensions20ExtensionMessagePortEFvPN7content15RenderFrameHostEEvE6InvokeIS8_PS3_JS6_EEEvT_OT0_DpOT1_
#18 0x55566c8f60af _ZN4base8internal12InvokeHelperILb0EvE8MakeItSoIRKMN10extensions20ExtensionMessagePortEFvPN7content15RenderFrameHostEEJPS5_S8_EEEvOT_DpOT0_
#19 0x5556748b97f5 _ZN4base8internal7InvokerINS0_9BindStateIMN8chromeos10smb_dialog10SmbHandlerEFvPKNS_9ListValueEEJNS0_17UnretainedWrapperIS5_EEEEEFvS8_EE7RunImplIRKSA_RKNSt3__15tupleIJSC_EEEJLm0EEEEvOT_OT0_NSJ_16integer_sequenceImJXspT1_EEEEOS8_
#20 0x5556748b9724 _ZN4base8internal7InvokerINS0_9BindStateIMN8chromeos10smb_dialog10SmbHandlerEFvPKNS_9ListValueEEJNS0_17UnretainedWrapperIS5_EEEEEFvS8_EE3RunEPNS0_13BindStateBaseES8_
#21 0x7f4ac0d42120 _ZNKR4base17RepeatingCallbackIFvPN7content11WebContentsEEE3RunES3_
#22 0x7f4ac337abdd content::WebUIImpl::ProcessWebUIMessage()
#23 0x7f4ac3377d98 content::WebUIImpl::OnWebUISend()
#24 0x7f4ac337b92e _ZN3IPC20DispatchToMethodImplIN7content9WebUIImplEMS2_FvPNS1_15RenderFrameHostERKNSt3__112basic_stringIcNS5_11char_traitsIcEENS5_9allocatorIcEEEERKN4base9ListValueEES3_NS5_5tupleIJSB_SF_EEEJLm0ELm1EEEEvPT_T0_PT1_OT2_NS5_16integer_sequenceImJXspT3_EEEE
#25 0x7f4ac337b850 _ZN3IPC16DispatchToMethodIN7content9WebUIImplENS1_15RenderFrameHostEJRKNSt3__112basic_stringIcNS4_11char_traitsIcEENS4_9allocatorIcEEEERKN4base9ListValueEENS4_5tupleIJSA_SE_EEEEENS4_9enable_ifIXeqsZT1_sr3std10tuple_sizeINS4_5decayIT2_E4typeEEE5valueEvE4typeEPT_MSQ_FvPT0_DpT1_EST_OSL_
#26 0x7f4ac337b54e _ZN3IPC8MessageTI27FrameHostMsg_WebUISend_MetaNSt3__15tupleIJNS2_12basic_stringIcNS2_11char_traitsIcEENS2_9allocatorIcEEEEN4base9ListValueEEEEvE8DispatchIN7content9WebUIImplESG_NSF_15RenderFrameHostEMSG_FvPSH_RKS9_RKSB_EEEbPKNS_7MessageEPT_PT0_PT1_T2_
#27 0x7f4ac3377b0c content::WebUIImpl::OnMessageReceived()
#28 0x7f4ac329d21e content::WebContentsImpl::OnMessageReceived()
#29 0x7f4ac27e345c content::RenderFrameHostImpl::OnMessageReceived()
#30 0x7f4ac2e8c923 content::RenderProcessHostImpl::OnMessageReceived()
#31 0x7f4ac682c605 IPC::ChannelProxy::Context::OnDispatchMessage()
#32 0x7f4ac68323ef _ZN4base8internal13FunctorTraitsIMN3IPC12ChannelProxy7ContextEFvRKNS2_7MessageEEvE6InvokeIS9_RK13scoped_refptrIS4_EJS7_EEEvT_OT0_DpOT1_
#33 0x7f4ac683234f _ZN4base8internal12InvokeHelperILb0EvE8MakeItSoIRKMN3IPC12ChannelProxy7ContextEFvRKNS4_7MessageEEJRK13scoped_refptrIS6_ES9_EEEvOT_DpOT0_
#34 0x7f4ac68322dd _ZN4base8internal7InvokerINS0_9BindStateIMN3IPC12ChannelProxy7ContextEFvRKNS3_7MessageEEJ13scoped_refptrIS5_ES6_EEEFvvEE7RunImplIRKSA_RKNSt3__15tupleIJSC_S6_EEEJLm0ELm1EEEEvOT_OT0_NSJ_16integer_sequenceImJXspT1_EEEE
#35 0x7f4ac68321dc _ZN4base8internal7InvokerINS0_9BindStateIMN3IPC12ChannelProxy7ContextEFvRKNS3_7MessageEEJ13scoped_refptrIS5_ES6_EEEFvvEE3RunEPNS0_13BindStateBaseE
#36 0x7f4ac9b9f3de _ZNO4base12OnceCallbackIFvvEE3RunEv
#37 0x7f4ac9beeaba base::debug::TaskAnnotator::RunTask()
#38 0x7f4ac9c8047c base::MessageLoopImpl::RunTask()
#39 0x7f4ac9c8077b base::MessageLoopImpl::DeferOrRunPendingTask()
#40 0x7f4ac9c80fb4 base::MessageLoopImpl::DoWork()
#41 0x7f4ac9f45339 base::MessagePumpLibevent::Run()
#42 0x7f4ac9c7fc96 base::MessageLoopImpl::Run()
#43 0x7f4ac9d2b8b2 base::RunLoop::Run()
#44 0x55566fb94b8e ChromeBrowserMainParts::MainMessageLoopRun()
#45 0x7f4ac2213683 content::BrowserMainLoop::RunMainMessageLoopParts()
#46 0x7f4ac221ba40 content::BrowserMainRunnerImpl::Run()
#47 0x7f4ac2206b7e content::BrowserMain()
#48 0x7f4ac44b9c20 content::RunBrowserProcessMain()
#49 0x7f4ac44bc7c6 content::ContentMainRunnerImpl::Run()
#50 0x7f4ac44b2a3c content::ContentServiceManagerMainDelegate::RunEmbedderProcess()
#51 0x7f4a9736f4c1 service_manager::Main()
#52 0x7f4ac44b7355 content::ContentMain()
#53 0x55566b93f606 ChromeMain
#54 0x55566b93f512 main
#55 0x7f4a9934b2b1 __libc_start_main
#56 0x55566b93f3ea _start

The DCHECK is firing because UDPSocketPosix::RecvFrom is calling base::MessageLoopCurrentForIO::Get() on the UI thread.  NB this DCHECK isn't checking anything new, before my patch it was:
  DCHECK_EQ(MessageLoop::TYPE_IO, loop->type());

I synced back to the patch before mine (sha hash 487f0f4e635c) and it still crashes.

Anyway it looks like there's a bug in the threading assumptions of chromeos::smb_client. The net code (correctly AFAICT) assumes the socket operation happens on the IO thread but the IPC and the call chain are on the UI thread.  I think you probably need a thread hop in there somewhere, perhaps in SmbHandler::HandleStartDiscovery? 

I'm assigning this to jimmyxgong@ fro triage because it looks like they've worked on code in the area.

It looks like the threading + thread assumptions should be handled a layer or two deeper, perhaps on MDnsClientImpl. The best fix may be to migrate MdnsClientImpl to mojom::UdpSocket