mayerwin / vs-customize-window-title

Customize Visual Studio Window Title - Visual Studio Extension
https://marketplace.visualstudio.com/items?itemName=mayerwin.RenameVisualStudioWindowTitle
MIT License
108 stars 30 forks source link

VS 2019 16.2.x freezes (at least on solution/VS close) #51

Closed rizi closed 2 years ago

rizi commented 5 years ago

Thx to JetBrains and MS we figured out the problem:

Sergey Kuks commented an hour ago Thread 367 WARNING: Stack pointer is outside the normal stack bounds. Stack unwinding can be inaccurate.

ChildEBP RetAddr

00 b233e200 75a88503 ntdll!NtWaitForMultipleObjects(void)+0xc [minkernel\ntdll\wow6432\objfre\i386\usrstubs.asm @ 825]

01 b233e394 77a85723 KERNELBASE!WaitForMultipleObjectsEx(unsigned long nCount = 1, void ** lpHandles = 0xb233e3e0, int bWaitAll = 0n0, unsigned long dwMilliseconds = 0xffffffff, int bAlertable = 0n0)+0x133 [minkernel\kernelbase\synch.c @ 1551]

02 b233e404 77abaf86 combase!MTAThreadWaitForCall(class CSyncClientCall * pClientCall = 0x94b06b30, WaitForCallReason reason = WaitingForReply (0n0), unsigned long dwRetryTimeout = 0xffffffff)+0x103 [onecore\com\combase\dcomrem\channelb.cxx @ 7429]

03 b233e494 77abab51 combase!MTAThreadDispatchCrossApartmentCall(struct tagRPCOLEMESSAGE pMessage = 0xb233e7e4, class OXIDEntry pOXIDEntry = 0x00988bb0, class CSyncClientCall * pClientCall = 0x94b06b30)+0xe6 [onecore\com\combase\dcomrem\chancont.cxx @ 235]

04 (Inline) -------- combase!CSyncClientCall::SwitchAptAndDispatchCall+0x306 [onecore\com\combase\dcomrem\channelb.cxx @ 6026]

05 b233e5b8 77aba2dd combase!CSyncClientCall::SendReceive2(struct tagRPCOLEMESSAGE pMessage = 0xb233e7e4, unsigned long pstatus = 0xb233e7c0)+0x3e1 [onecore\com\combase\dcomrem\channelb.cxx @ 5722]

06 (Inline) -------- combase!SyncClientCallRetryContext::SendReceiveWithRetry+0x2d [onecore\com\combase\dcomrem\callctrl.cxx @ 1641]

07 (Inline) -------- combase!CSyncClientCall::SendReceiveInRetryContext+0x2d [onecore\com\combase\dcomrem\callctrl.cxx @ 571]

08 (Inline) -------- combase!DefaultSendReceive+0x75 [onecore\com\combase\dcomrem\callctrl.cxx @ 529]

09 b233e79c 77a798d4 combase!CSyncClientCall::SendReceive(struct tagRPCOLEMESSAGE pMessage = 0xb233e7e4, unsigned long pulStatus = 0xb233e7c0)+0x1bd [onecore\com\combase\dcomrem\ctxchnl.cxx @ 817]

0a (Inline) -------- combase!CClientChannel::SendReceive+0x75 [onecore\com\combase\dcomrem\ctxchnl.cxx @ 696]

0b b233e7c4 75825d81 combase!NdrExtpProxySendReceive(void pThis = 0x46c2ddcc, struct _MIDL_STUB_MESSAGE pStubMsg = 0xb233e8cc)+0xc4 [onecore\com\combase\ndr\ndrole\proxy.cxx @ 1961]

0c (Inline) -------- rpcrt4!NdrpProxySendReceive+0x1b [minio\rpc\ndr20\mulsyntx.cxx @ 1566]

0d b233ecb8 77b2d450 rpcrt4!NdrClientCall2(struct _MIDL_STUB_DESC pStubDescriptor = 0x214ab1ec, unsigned char pFormat = 0x214ab1d6 "3l")+0x561 [minio\rpc\ndr20\cltcall.cxx @ 1107]

0e b233ecd8 77b253ef combase!ObjectStublessClient(void * ParamAddress = 0xb233ecf0, long Method = 0n19)+0x70 [onecore\com\combase\ndr\ndrole\i386\stblsclt.cxx @ 227]

0f b233ece8 6b2f691a combase!ObjectStubless(void)+0xf [onecore\com\combase\ndr\ndrole\i386\stubless.asm @ 171]

10 b233ed58 3c529b8e EnvDTE80_ni!DomainNeutralILStubClass.IL_STUB_CLRtoCOM(<Win32 error 0n318>)+0x72

11 b233eda4 3c529966 CustomizeVSWindowTitle!ErwinMayerLabs.RenameVSWindowTitle.CustomizeVSWindowTitle.UpdateWindowTitle(<Win32 error 0n318>)+0x20e

12 b233edb4 733a7118 CustomizeVSWindowTitle!ErwinMayerLabs.RenameVSWindowTitle.CustomizeVSWindowTitle.b__36_0(<Win32 error 0n318>)+0x6

13 b233edb4 733a6cc0 mscorlib_ni!System.Threading.Tasks.Task.InnerInvoke(<Win32 error 0n318>)+0x28 [f:\dd\ndp\clr\src\BCL\system\threading\Tasks\Task.cs @ 2884]

14 b233edd8 733a70ea mscorlib_ni!System.Threading.Tasks.Task.Execute(<Win32 error 0n318>)+0x30 [f:\dd\ndp\clr\src\BCL\system\threading\Tasks\Task.cs @ 2498]

15 b233ee40 733c40c5 mscorlib_ni!System.Threading.Tasks.Task.ExecutionContextCallback(<Win32 error 0n318>)+0x1a [f:\dd\ndp\clr\src\BCL\system\threading\Tasks\Task.cs @ 2861]

16 b233ee40 733c3fd6 mscorlib_ni!System.Threading.ExecutionContext.RunInternal(<Win32 error 0n318>)+0xe5 [f:\dd\ndp\clr\src\BCL\system\threading\executioncontext.cs @ 954]

17 b233ee54 733a6f68 mscorlib_ni!System.Threading.ExecutionContext.Run(<Win32 error 0n318>)+0x16 [f:\dd\ndp\clr\src\BCL\system\threading\executioncontext.cs @ 902]

18 b233eec0 733a6e72 mscorlib_ni!System.Threading.Tasks.Task.ExecuteWithThreadLocal(<Win32 error 0n318>)+0xd8 [f:\dd\ndp\clr\src\BCL\system\threading\Tasks\Task.cs @ 2827]

19 b233eed0 733a6dbc mscorlib_ni!System.Threading.Tasks.Task.ExecuteEntry(<Win32 error 0n318>)+0xb2 [f:\dd\ndp\clr\src\BCL\system\threading\Tasks\Task.cs @ 2756]

1a b233ef24 7336dba2 mscorlib_ni!System.Threading.Tasks.Task.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem(<Win32 error 0n318>)+0xc [f:\dd\ndp\clr\src\BCL\system\threading\Tasks\Task.cs @ 2704]

1b b233ef24 7336da0a mscorlib_ni!System.Threading.ThreadPoolWorkQueue.Dispatch(<Win32 error 0n318>)+0x192 [f:\dd\ndp\clr\src\BCL\system\threading\threadpool.cs @ 820]

1c b233ef34 7447ebe6 mscorlib_ni!System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(<Win32 error 0n318>)+0xa [f:\dd\ndp\clr\src\BCL\system\threading\threadpool.cs @ 1161]

1d b233ef34 74481e50 clr!CallDescrWorkerInternal(unsigned long pParams = 0xb233efd0)+0x34 [f:\dd\ndp\clr\src\vm\i386\asmhelpers.asm @ 763]

1e b233ef88 744879f4 clr!CallDescrWorkerWithHandler(struct CallDescrData * pCallDescrData = 0xb233efd0, int fCriticalCall = 0n0)+0x6b [f:\dd\ndp\clr\src\vm\callhelpers.cpp @ 91]

1f b233effc 7448b673 clr!MethodDescCallSite::CallTargetWorker(unsigned int64 * pArguments = 0x00000000)+0x16a [f:\dd\ndp\clr\src\vm\callhelpers.cpp @ 655]

20 (Inline) -------- clr!MethodDescCallSite::Call_RetBool+0xb [f:\dd\ndp\clr\src\vm\callhelpers.h @ 423]

21 b233f07c 7448a059 clr!QueueUserWorkItemManagedCallback(void * pArg = 0xb233f297)+0x23 [f:\dd\ndp\clr\src\vm\comthreadpool.cpp @ 510]

22 b233f090 7448a0c3 clr!ManagedThreadBase_DispatchInner(struct ManagedThreadCallState * pCallState = 0x7448b650)+0x71 [f:\dd\ndp\clr\src\vm\threads.cpp @ 10273]

23 b233f134 7448a190 clr!ManagedThreadBase_DispatchMiddle(struct ManagedThreadCallState * pCallState = 0xb233f198)+0x7e [f:\dd\ndp\clr\src\vm\threads.cpp @ 10323]

24 b233f190 7448a1ff clr!ManagedThreadBase_DispatchOuter(struct ManagedThreadCallState * pCallState = 0xb233f198)+0x5b [f:\dd\ndp\clr\src\vm\threads.cpp @ 10577]

25 b233f1b4 7448b601 clr!ManagedThreadBase_FullTransitionWithAD(struct ADID pAppDomain = struct ADID, pTarget = , void args = , UnhandledExceptionLocation filterType = ThreadPoolThread (0n4))+0x2f [f:\dd\ndp\clr\src\vm\threads.cpp @ 10641]

26 (Inline) -------- clr!ManagedThreadBase::ThreadPool+0x10 [f:\dd\ndp\clr\src\vm\threads.cpp @ 10682]

27 b233f264 7448a45b clr!ManagedPerAppDomainTPCount::DispatchWorkItem(bool foundWork = 0xb233f295, bool wasNotRecalled = 0xb233f297)+0x102 [f:\dd\ndp\clr\src\vm\threadpoolrequest.cpp @ 761]

28 b233f27c 7448a349 clr!ThreadpoolMgr::ExecuteWorkRequest(bool foundWork = 0xb233f295, bool wasNotRecalled = )+0x4f [f:\dd\ndp\clr\src\vm\win32threadpool.cpp @ 1878]

29 b233f2e4 744feda1 clr!ThreadpoolMgr::WorkerThreadStart(void * lpArgs = 0x00000000)+0x3d3 [f:\dd\ndp\clr\src\vm\win32threadpool.cpp @ 2346]

2a b233fa80 775b0419 clr!Thread::intermediateThreadProc(void * arg = 0x6e1cdf48)+0x55 [f:\dd\ndp\clr\src\vm\threads.cpp @ 2872]

2b b233fa90 77cd662d kernel32!BaseThreadInitThunk(unsigned long RunProcessInit = , StartAddress = 0x744fed50, void Argument = 0x6e1cdf48)+0x19 [base\win32\client\thread.c @ 64]

2c b233faec 77cd65fd ntdll!__RtlUserThreadStart( StartAddress = 0x744fed50, void Argument = )+0x2f [minkernel\ntdll\rtlstrt.c @ 1163]

2d b233fafc 00000000 ntdll!_RtlUserThreadStart( StartAddress = , void Argument = )+0x1b [minkernel\ntdll\rtlstrt.c @ 1080]

These kinds of issues are almost always caused by a background thread trying to get back to the main thread using RPC instead of JTF. In this case it looks like the culprit is thread 367 (!), where ErwinMayerLabs.RenameVSWindowTitle.CustomizeVSWindowTitle.UpdateWindowTitle is calling some DTE method. The DTE method is STA and needs to run on the main thread. The fix would be to transition to the main thread before making the DTE call. A workaround might be to disable the CustomizeVSWindowTitle extension.

Details: https://youtrack.jetbrains.com/issue/RSRP-476094

mayerwin commented 5 years ago

Thanks, do you know why this wouldn't be simply caught as an exception and ignored?

mayerwin commented 5 years ago

We're only invoking the UI thread in ChangeWindowTitle (to set the window name), not for read-only access of the DTE object (which would otherwise slow down the UI).

rizi commented 5 years ago

Unfortunately I don't know. I thought you maybe accessed DTE not from the main thread. That would be the reason why VS freezes. In CustomizeVSWindowTitlePackage.cs I think you access DTE directly on some events I don't know if that's always the UI thread, but I have to say I don't develop VS extensions myself.

mayerwin commented 5 years ago

Could changing the compartment of the thread from MTA to STA be sufficient to solve the issue?

mayerwin commented 5 years ago

Are you able to easily reproduce the issue (so we can see if just changing the threading compartment is sufficient)?

mayerwin commented 5 years ago

Hum, normally the code already runs on the UI thread since it is triggered by a System.Windows.Forms.Timer, which should already be STA.

rizi commented 5 years ago

It doesn't happen always, but I can give it a try if you want