Fusion 360 will not start

[jismacgregor]

Hi,

I am having problems starting Fusion 360 today. I use windows and have been using it for about 12 months without any problems.

When I click on the icon, nothing happens. No error message. It just doesn't start. I don't get the splash screen.

I have recently done the windows update to version 1903. Has this broken it in some way?

James

[karina.harper]

Hey @jismacgregor 

Have you tried a clean uninstall?

If not, go ahead and do that, then start running through this article.

I would also try right click -> run as administrator.

Does any of that help?

Cheers,

Karina

[jismacgregor · Accepted solution]

Hi,

I fixed this. It was the 1903 upgrade to windows which broke it (I think).

I noticed that sketchup was also refusing to start. Sketchup gave me an error message though, which pointed me to my graphics card being the issue. So I checked my drivers on my PC and discovered that the driver for the graphics card had a newer version - which I installed. Now both sketchup and Fusion 360 start.

I can't properly explain it, but I suspect that 1903 did some changes which made the graphics card upgrade necessary too.

James.

[antswanmail]

Hi James,

I'm also having trouble starting Fusion in Windows 10 after a factory reset of Windows. Can you please tell me what Graphics card you have and what driver you installed. 

Thanks, Anthony

[jismacgregor]

I have a DELL Inspiron 5567 laptop with the standard AMD Radeon R7 M445 graphics card. My driver version is now 19.10.16 which is the latest version.

As I said though, I cannot be 100% sure that it was the update to the graphics card software which fixed the problem or windows update which broke it originally!

James.

[Anonymous]

I've the same problem... (windows 19033.1)
I made the graphic driver update to the latest version
I made a clean uninstall of Fusion and install it again
I've made a reboot and deactivate some part of Windows Defender
But it's always the same... I see it on the task manager 0% and 14Mb ram used but nothing append !

If someone have an idea... 
Tanks

[ichX5HMP]

same issue after windows update 19033.1

clean install did not worked.

13.9 Mb, 0% in Taskmanager

MS Surface Book 2

[Anonymous]

I am one of you who cannot start Fusion 360. I am using Windows 10 Insider Preview, version 1903, build 19028.

I never started Fusion 360 before, though I tried many times. It just won't launch. No splash screen, no error, There's only a process that takes up RAM and does nothing.

I've even tried to update video card drivers, GeForce Experience says my drivers are up to date. I've also tried reinstalling Fusion, didn't fix it. There are Windows updates installed and waiting to restart computer, so I'll see if that will fix it, but I doubt that.

[Anonymous]

I'm able to replicate this issue on my Desktop running W10.0.19033 with a discrete nvidia 2080, my surface pro 6 running 19031 and my surface laptop running 19033, as well as in Windows Sandbox on all 3 machines to simulate the cleanest of clean reinstalls.

nvidia driver: 445.23 10/01/2019

The pre-existing fusion install stopped working, so I eventually uninstalled, rebooted, ran the Fusion 360 Cleaner, rebooted, re-installed, and still no go.

Fusion Launcher starts and one instance of Fusion 360 shows up as a service rather than as a process, and then nothing happens.

I dual booted the desktop machine to the last non-insider build but with the same nvidia driver I was using under 19033 and Fusion ran there.

[Anonymous]

So this is most likely issue of Windows Insider then? I just wanted to see how my PCB would look like assembled 😞 I installed Fusion 360 because EAGLE requires it for 3D view of PCB.

[karina.harper]

Hi @Anonymous @jismacgregor @Anonymous @ichX5HMP @Anonymous 

Thanks for commenting - yes it sounds like this is due to the insider preview. We don't develop for the IP and so it's not currently supported for Fusion.

You are welcome to give this kind of feedback about how Fusion performs, but we've definitely seen this happen frequently with the insider preview. Your best bet is to revert to the supported build of Windows.

Cheers,

Karina

[Anonymous]

This is not as simple as "it's due to Windows Insider". Part of the reason Windows Insider exists is so vendors can get ahead of compatibility issues of their software before it hits the general population of their users.

Chalking this up to it being an "insiders" issue is going to lead up to this not working in the main release, at which point users will be exposing themselves to security vulnerabilities if they don't upgrade to a version of Windows which Fusion 360 won't run in.

As for "seeing this problem frequently", as far as I have been able to determine, it looks like this same thing has happened only once before, back in 2018, and it took Autodesk months to fix the problem.

This time we're here letting them know ahead of time, and instead of saying "we're going to look into it"... and it really seems like you're giving it the brush-off.

Not the best move after you just changed all your licensing plans. If this is how you treat product development and support, I have no confidence that I won't be out hundreds of dollars and wind up with a product that doesn't work.

I've been a software developer for 15 years. I'm not being unreasonable and expecting a solution for a build target that is unstable, but I am expecting you to acknowledge and inform users that this is a known problem with latest Windows builds, and at least attempt to determine the cause and either report bugs to MS or reaffirm to users that this problem won't impact users once this build of Windows moves to the stable ring.

[Anonymous]

You nailed it!

[karina.harper]

Hi @Anonymous 

Thanks for the response. Since there are quite a few threads on this, I'm going to re-post one of my answers here:

While it isn't supported, we're happy to receive your feedback on IP and develop to improve Fusion for when IP becomes the next update. My advice to roll back comes from a support standpoint, not a development standpoint. 

There are a few threads that are gathering data about Fusion failing to launch on IP, but feel free to add any information you have about Fusion failing to launch here and I'll add it to the internal ticket. 

As this is the Fusion 360 support forum, our first priority is to get users working again. If Fusion is not launching when using the IP build, my first recommendation is going to be to roll back. 

I apologize if my response made it seem like we don't care about this issue - we certainly do. It has been a huge conversation internally.

Hope that makes sense,

Karina

[Anonymous]

Hi Karina, thanks for following up!

This clarification was very helpful and very reassuring!
I knew from a support standpoint the solution would be to roll back, and I wasn't upset about that at all... I just wanted to hear that there was some development focus on the issue so that we could collaborate as needed with developers to get them any local information they might need to get ahead of this before it makes it to Windows stable.
I dumped some logs and about half a dozen mitigation steps I took in the other thread, so I'm sure you've already got that information in the internal issue tracker.
If you want to doublecheck that it's included, here's a link to my troubleshooting efforts: https://forums.autodesk.com/t5/fusion-360-support/fusion360-won-t-start-on-latest-windows-10-insider... (https://link.getmailspring.com/link/B87CA9A6-C6CE-41C1-BB2A-85C538DB5857@getmailspring.com/0?redirec...)

[Anonymous]

---

@Anonymous wrote:

This is not as simple as "it's due to Windows Insider". Part of the reason Windows Insider exists is so vendors can get ahead of compatibility issues of their software before it hits the general population of their users.

...
I've been a software developer for 15 years. I'm not being unreasonable and expecting a solution for a build target that is unstable, but I am expecting you to acknowledge and inform users that this is a known problem with latest Windows builds, and at least attempt to determine the cause and either report bugs to MS or reaffirm to users that this problem won't impact users once this build of Windows moves to the stable ring.

---

Windows Insiders Build is how Microsoft makes new builds available to developers.  WIB has replaced MSDN Preview Builds.

So, it literally couldn't be any simpler than this just being the Windows Insider Build. Contrary to your reply, AutoDesk had already acknowledged the conflict and that they were looking into it, and I think that's a pretty reasonable turn-around for free forum-based support.

[Anonymous]

Digging a bit deeper it looks like a deadlock between Fusion360 and RCPSS happening within: 

PushSubscriberEventSource::unsubscribe 

or at a deeper level within

CPubINetworkListManager::GetPrivateNetworkListManager

My 30 second guess is that it is hanging waiting to unsubscribe from the private network event source.

 Stack text:

0000008c`8fafcb58 00007ffd`82493d9f : 0000008c`8fafd319 0000008c`8fafceb0 0000008c`8fafd2c0 0000008c`8fafceb0 : ntdll!NtAlpcSendWaitReceivePort+0x14
0000008c`8fafcb60 00007ffd`824a8c87 : 00000000`00000000 00007ffd`829d1420 0000008c`8fafcd00 0000008c`8fafd319 : RPCRT4!LRPC_BASE_CCALL::SendReceive+0x12f
0000008c`8fafcc30 00007ffd`824517f0 : 00000000`00000000 0000019c`73426d40 0000008c`8fafd319 00000000`00000000 : RPCRT4!NdrpSendReceive+0x97
0000008c`8fafcc60 00007ffd`8245120f : 00000000`00000000 0000008c`8fafd4b0 00000000`00000000 0000008c`8fafd4b0 : RPCRT4!NdrpClientCall2+0x5d0
0000008c`8fafd280 00007ffd`827b92b1 : 0000798f`b3680ca3 00007ffd`82a1e158 0000019c`73426d40 0000019c`77963d80 : RPCRT4!NdrClientCall2+0x1f
0000008c`8fafd2b0 00007ffd`827b912d : 00000000`00000000 00000000`00000000 0000008c`8fafd4b0 0000019c`77812380 : combase!CoGetCurrentLogicalThreadId+0x58f1
0000008c`8fafd370 00007ffd`827b9981 : 0000019c`779f80e0 0000008c`8fafd580 00000000`00000014 00000000`00000000 : combase!CoGetCurrentLogicalThreadId+0x576d
0000008c`8fafd480 00007ffd`827eb6cf : 0000019c`779f80e0 0000019c`779f80e0 00000000`00000000 0000019c`77804320 : combase!CoGetCurrentLogicalThreadId+0x5fc1
0000008c`8fafd630 00007ffd`827efaf2 : 00000000`00000000 00000000`00000000 0000019c`77812380 0000008c`8fafdab0 : combase!CoMarshalInterface+0x431f
0000008c`8fafd6a0 00007ffd`827fe5a3 : 0000019c`77804320 00007ffd`8280013f 00000000`00000001 0000008c`8fafe768 : combase!CoGetStandardMarshal+0x4e2
0000008c`8fafd6d0 00007ffd`827fdfd0 : 00000000`00000000 00000000`00000000 0000019c`77804320 00000000`00000010 : combase!CoGetTreatAsClass+0x1bd3
0000008c`8fafd710 00007ffd`82863206 : 0000008c`8fafdec8 0000008c`8fafe768 00000000`00000000 0000008c`8fafd930 : combase!CoGetTreatAsClass+0x1600
0000008c`8fafd8d0 00007ffd`827fcf05 : 0000008c`8fafdec8 0000008c`8fafdb60 0000008c`8fafd930 00000000`00000000 : combase!CoGetModuleArchitecture+0x7f6
0000008c`8fafd900 00007ffd`82800610 : 0000008c`8fafdec8 ffffff73`70502370 00000000`00000000 00000000`80004005 : combase!CoGetTreatAsClass+0x535
0000008c`8fafdbb0 00007ffd`8280b7ba : 00000000`00000000 0000008c`8fafe6f0 00000000`00000001 00000000`00000000 : combase!CoGetTreatAsClass+0x3c40
0000008c`8fafdc40 00007ffd`8280a289 : 0000008c`8fafed78 0000019c`7799ace0 0000019c`7799ace0 00007ffd`8413047c : combase!CoCreateInstance+0x17fa
0000008c`8fafeb10 00007ffd`8280a0cc : 00007ffd`84136940 00000001`00000000 0000008c`00000048 00007ffd`81cacb17 : combase!CoCreateInstance+0x2c9
0000008c`8fafec70 00007ffd`7cdd6cc1 : 0000019c`77816ca0 0000008c`8fafee90 0000008c`8fafeda9 00007ffd`00000004 : combase!CoCreateInstance+0x10c
0000008c`8fafed10 00007ffd`7cdd62b6 : 00000000`00000000 0000019c`779f37b0 0000019c`77816ca0 00000000`00000001 : netprofm!CPubINetworkListManager::GetPrivateNetworkListManager+0x1f1
0000008c`8fafee10 00007ffd`7cdd5825 : 00000000`00000000 0000019c`77816ca0 00000000`00000000 00000000`00000001 : netprofm!CPubINetworkListManager::FinalRelease+0xc6
0000008c`8fafee90 00007ffd`7cdd799b : 00000000`00000000 00000000`00000000 00000000`00000001 00000000`00000000 : netprofm!ATL::CComObject<CPubINetworkListManager>::`scalar deleting destructor'+0x85
0000008c`8fafeec0 00007ffd`0f6a8a92 : 00007ffd`0faefaa8 0000008c`8faff930 00000000`00000000 00000000`00000001 : netprofm!ATL::CComObject<CPubINetworkListManager>::Release+0x4b
0000008c`8fafeef0 00007ffd`0f6a8d7f : 0000019c`77816d20 00000000`00000001 00007ffd`56da0060 00000000`00000001 : NsBase10!Ns::OS::NetworkMonitor::_get+0x122
0000008c`8fafef40 00007ffd`0f58e65e : 00007ffd`56da0060 00000000`0000000a 00000000`00000000 00000000`00000000 : NsBase10!Ns::OS::NetworkMonitor::get+0xdf
0000008c`8fafefa0 00007ffd`56d56ff0 : 00007ffd`56da0100 00000000`0000000a 00000000`00000000 00007ffd`56da0100 : NsBase10!Ns::CloudStatusManager::subscribe+0xe
0000008c`8fafefd0 00007ffd`56d51160 : 00007ffd`56d85e00 00007ffd`56d85e08 00000000`0000000a bc000400`00000000 : NsPushNotifications10!Ns::PushNotificationManager::PushNotificationManager+0xf0
0000008c`8faff070 00007ffd`8184de83 : 00000000`00000007 00000000`00000000 0000008c`8faff930 00007ffd`5976885f : NsPushNotifications10+0x1160
0000008c`8faff0a0 00007ffd`56d80e92 : 00000000`00000000 0000008c`8faff430 0000008c`8faff930 00007ffd`84127b23 : ucrtbase!initterm+0x43
0000008c`8faff0d0 00007ffd`56d81008 : 00000000`00000001 0000008c`8faff930 00000000`00000000 00000000`00000001 : NsPushNotifications10!Ns::PushSubscriberEventSource::unsubscribe+0x1d8c2
0000008c`8faff100 00007ffd`84127bad : 00007ffd`56d50000 00000000`00000001 0000008c`8faff930 00000000`7ffe0385 : NsPushNotifications10!Ns::PushSubscriberEventSource::unsubscribe+0x1da38
0000008c`8faff160 00007ffd`84153493 : 0000019c`733a5630 00007ffd`56d50000 00007ffd`00000001 00007ffd`56d804a0 : ntdll!LdrpCallInitRoutine+0x61
0000008c`8faff1d0 00007ffd`84153226 : 0000019c`733b2670 0000019c`733b2600 0000008c`8faff401 0000019c`00000001 : ntdll!LdrpInitializeNode+0x1d3
0000008c`8faff320 00007ffd`841532ac : 0000019c`73396000 0000019c`733962e0 0000008c`8faff430 0000019c`733b8610 : ntdll!LdrpInitializeGraphRecurse+0x42
0000008c`8faff360 00007ffd`841532ac : 0000008c`8f890000 0000019c`73393ec0 0000008c`8faff430 0000019c`733a2a70 : ntdll!LdrpInitializeGraphRecurse+0xc8
0000008c`8faff3a0 00007ffd`841c2d06 : 00000000`00000000 00000000`00000010 00000000`00000000 00007ffd`842206e0 : ntdll!LdrpInitializeGraphRecurse+0xc8
0000008c`8faff3e0 00007ffd`841b12f1 : 00000000`00000001 00000000`00000000 00000000`00000000 00000000`00000001 : ntdll!LdrpInitializeProcess+0x1fd6
0000008c`8faff810 00007ffd`841645b3 : 00000000`00000000 00007ffd`840f0000 00000000`00000000 0000008c`8f891000 : ntdll!_LdrpInitialize+0x4cd25
0000008c`8faff8b0 00007ffd`8416455e : 0000008c`8faff930 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!LdrpInitialize+0x3b
0000008c`8faff8e0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!LdrInitializeThunk+0xe

 Symbol info on hang:

SYMBOL_NAME:  NsPushNotifications10!Ns::PushSubscriberEventSource::unsubscribe+1da38
MODULE_NAME: NsPushNotifications10IMAGE_NAME:  NsPushNotifications10.dll
FAILURE_BUCKET_ID:  APPLICATION_HANG_HungIn_LoaderLock_cfffffff_NsPushNotifications10.dll!Ns::PushSubscriberEventSource::unsubscribe
OS_VERSION:  10.0.19035.1

Dropping from user mode to kernel give the following ALPC wait info: (Note process and thread is different to above, callstacks will not align)

---

---

THREAD ffffe288da5c9080 Cid 10ac.11bc Teb: 0000003991573000 Win32Thread: ffffe288e1b36c30 WAIT: (WrLpcReply) UserMode Non-Alertable
ffffe288da5c9508 Semaphore Limit 0x1
Waiting for reply to ALPC Message ffffb20de6a85c60 : queued at port ffffe288cb341aa0 : owned by process ffffe288cb33c0c0
Not impersonating
DeviceMap ffffb20dca2c2d50
Owning Process ffffe288cf708300 Image: Fusion360.exe

 With ALPC message being:

Message ffffb20de6a85c60
MessageID : 0x2F90 (12176)
CallbackID : 0x2FA90F (3123471)
SequenceNumber : 0x00000006 (6)
Type : LPC_REQUEST
DataLength : 0x0192 (402)
TotalLength : 0x01BA (442)
Canceled : No
Release : No
ReplyWaitReply : No
Continuation : Yes
OwnerPort : ffffe288daee7ac0 [ALPC_CLIENT_COMMUNICATION_PORT]
WaitingThread : ffffe288da5c9080
QueueType : ALPC_MSGQUEUE_PENDING
QueuePort : ffffe288cb341aa0 [ALPC_CONNECTION_PORT]
QueuePortOwnerProcess : ffffe288cb33c0c0 (svchost.exe)
ServerThread : ffffe288ce460080
QuotaCharged : No
CancelQueuePort : 0000000000000000
CancelSequencePort : 0000000000000000
CancelSequenceNumber : 0x00000000 (0)
ClientContext : 0000020cd3951d40
ServerContext : 0000000000000000
PortContext : 0000013927204de0
CancelPortContext : 0000000000000000
SecurityData : 0000000000000000
View : 0000000000000000
HandleData : 0000000000000000

Dropping into the port (each way) we can in fact see the threads waiting for IO completion, alongside a single message in the pending queue from the port owned by svchost.exe (in this case RPCSS):

0: kd> !alpc /p ffffe288daee7ac0
Port ffffe288daee7ac0
Type : ALPC_CLIENT_COMMUNICATION_PORT
CommunicationInfo : ffffb20ddb7be560
ConnectionPort : ffffe288cb341aa0 (epmapper)
ClientCommunicationPort : ffffe288daee7ac0
ServerCommunicationPort : ffffe288daee7d20
OwnerProcess : ffffe288cf708300 (Fusion360.exe)
SequenceNo : 0x00000006 (6)
CompletionPort : 0000000000000000
CompletionList : 0000000000000000
ConnectionPending : No
ConnectionRefused : No
Disconnected : No
Closed : No
FlushOnClose : Yes
ReturnExtendedInfo : No
Waitable : No
Security : Dynamic
Wow64CompletionList : No
---
Main queue is empty.
Direct message queue is empty.
Large message queue is empty.
Pending queue is empty.
Canceled queue is empty.

0: kd> !alpc /p ffffe288cb341aa0
Port ffffe288cb341aa0
Type : ALPC_CONNECTION_PORT
CommunicationInfo : ffffb20dc7c9b090
ConnectionPort : ffffe288cb341aa0 (epmapper)
ClientCommunicationPort : 0000000000000000
ServerCommunicationPort : 0000000000000000
OwnerProcess : ffffe288cb33c0c0 (svchost.exe)
SequenceNo : 0x0000031D (797)
CompletionPort : ffffe288cb2df840
CompletionList : 0000000000000000
ConnectionPending : No
ConnectionRefused : No
Disconnected : No
Closed : No
FlushOnClose : Yes
ReturnExtendedInfo : No
Waitable : No
Security : Static
Wow64CompletionList : No
--
10 thread(s) are registered with port IO completion object:
THREAD ffffe288cb3472c0 Cid 043c.0460 Teb: 000000362e25e000 Win32Thread: 0000000000000000 WAIT
THREAD ffffe288cb663080 Cid 043c.07b4 Teb: 000000362e26e000 Win32Thread: 0000000000000000 WAIT
THREAD ffffe288cbef5080 Cid 043c.2aec Teb: 000000362e27a000 Win32Thread: 0000000000000000 WAIT
THREAD ffffe288cbe99080 Cid 043c.2af0 Teb: 000000362e27c000 Win32Thread: 0000000000000000 WAIT
THREAD ffffe288cbef25c0 Cid 043c.2af8 Teb: 000000362e280000 Win32Thread: 0000000000000000 WAIT
THREAD ffffe288d89de080 Cid 043c.6838 Teb: 000000362e2a2000 Win32Thread: ffffe288e1461b20 WAIT
THREAD ffffe288ce460080 Cid 043c.5aac Teb: 000000362e2ac000 Win32Thread: 0000000000000000 WAIT
THREAD ffffe288cf8ee040 Cid 043c.63ec Teb: 000000362e2b4000 Win32Thread: 0000000000000000 WAIT
THREAD ffffe288cea98080 Cid 043c.5084 Teb: 000000362e2ba000 Win32Thread: 0000000000000000 WAIT
THREAD ffffe288ce9e8080 Cid 043c.0d08 Teb: 000000362e2bc000 Win32Thread: 0000000000000000 WAIT
Main queue is empty.
Direct message queue is empty.
Large message queue is empty.
Pending queue has 1 message(s)
ffffb20de6a85c60 00002f90 00000000000010ac:00000000000011bc ffffe288da5c9080 ffffe288ce460080 LPC_REQUEST
Canceled queue is empty.

Digging into the server thread (within svchost.exe) for the fusion message, we actually see svchost.exe is waiting for a reply to an ALPC message! This is our lock, but why is this happening?! Taking a snip of both threads:

0: kd> !thread ffffe288ce460080
THREAD ffffe288ce460080 Cid 043c.5aac Teb: 000000362e2ac000 Win32Thread: 0000000000000000 WAIT: (WrLpcReply) UserMode Non-Alertable
ffffe288ce460508 Semaphore Limit 0x1
Waiting for reply to ALPC Message ffffb20dcb878c60 : queued at port ffffe288d77e09f0 : owned by process ffffe288cf708300
...
Owning Process ffffe288cb33c0c0 Image: svchost.exe
...

0: kd> !thread ffffe288da5c9080
THREAD ffffe288da5c9080 Cid 10ac.11bc Teb: 0000003991573000 Win32Thread: ffffe288e1b36c30 WAIT: (WrLpcReply) UserMode Non-Alertable
ffffe288da5c9508 Semaphore Limit 0x1
Waiting for reply to ALPC Message ffffb20de6a85c60 : queued at port ffffe288cb341aa0 : owned by process ffffe288cb33c0c0
...
Owning Process ffffe288cf708300 Image: Fusion360.exe
...

Digging into these 2 messages (with 1 being the same as above):

0: kd> !alpc /m ffffb20de6a85c60

Message ffffb20de6a85c60
MessageID : 0x2F90 (12176)
CallbackID : 0x2FA90F (3123471)
SequenceNumber : 0x00000006 (6)
Type : LPC_REQUEST
DataLength : 0x0192 (402)
TotalLength : 0x01BA (442)
Canceled : No
Release : No
ReplyWaitReply : No
Continuation : Yes
OwnerPort : ffffe288daee7ac0 [ALPC_CLIENT_COMMUNICATION_PORT]
WaitingThread : ffffe288da5c9080
QueueType : ALPC_MSGQUEUE_PENDING
QueuePort : ffffe288cb341aa0 [ALPC_CONNECTION_PORT]
QueuePortOwnerProcess : ffffe288cb33c0c0 (svchost.exe)
ServerThread : ffffe288ce460080


0: kd> !alpc /m ffffb20dcb878c60

Message ffffb20dcb878c60
MessageID : 0x4038 (16440)
CallbackID : 0x2FA911 (3123473)
SequenceNumber : 0x00000001 (1)
Type : LPC_CONNECTION_REQUEST
DataLength : 0x0000 (0)
TotalLength : 0x0028 (40)
Canceled : No
Release : No
ReplyWaitReply : No
Continuation : Yes
OwnerPort : ffffe288d8dc7ab0 [ALPC_CLIENT_COMMUNICATION_PORT]
WaitingThread : ffffe288ce460080
QueueType : ALPC_MSGQUEUE_MAIN
QueuePort : ffffe288d77e09f0 [ALPC_CONNECTION_PORT]
QueuePortOwnerProcess : ffffe288cf708300 (Fusion360.exe)
ServerThread : 0000000000000000

It appears as if we are waiting on an LPC_CONNECTION_REQUEST that isn't picked up (still sitting within ALPC_MSGQUEUE_MAIN), but are also waiting on LPC_REQUEST which has been processed (sitting within ALPC_MSGQUEUE_PENDING)!

The biggest pointer though is the ServerThread on message ffffb20dcb878c60 being '0000000000000000', meaning no thread is responsible for servicing the request!

Digging into the port:

0: kd> !alpc /p ffffe288d77e09f0
Port ffffe288d77e09f0
Type : ALPC_CONNECTION_PORT
CommunicationInfo : ffffb20ddb7be290
ConnectionPort : ffffe288d77e09f0 (OLE5799777E502DA20BE7BAC7C73517)
ClientCommunicationPort : 0000000000000000
ServerCommunicationPort : 0000000000000000
OwnerProcess : ffffe288cf708300 (Fusion360.exe)
SequenceNo : 0x00000001 (1)
CompletionPort : ffffe288d1fa2e40
CompletionList : 0000000000000000
ConnectionPending : No
ConnectionRefused : No
Disconnected : No
Closed : No
FlushOnClose : Yes
ReturnExtendedInfo : No
Waitable : No
Security : Static
Wow64CompletionList : No

Main queue has 1 message(s)
ffffb20dcb878c60 00004038 000000000000043c:0000000000005aac ffffe288ce460080 0000000000000000 LPC_CONNECTION_REQUEST

The concerning thing is we have no threads listed here with port IO completion! There is nothing hooked up to actually process this message! Is this a missing DCOM/OLE component?

Hopefully this is of some help, I'll keep digging around to see why this condition is happening.

[Anonymous]

One month later, I'm on 19041 OS Version and I still get the same hang with the same callstack. 

00 ntdll!NtAlpcSendWaitReceivePort01 RPCRT4!LRPC_BASE_CCALL::SendReceive02 RPCRT4!NdrpSendReceive03 RPCRT4!NdrpClientCall204 RPCRT4!NdrClientCall205 combase!CoGetCurrentLogicalThreadId06 combase!CoGetCurrentLogicalThreadId07 combase!CoGetCurrentLogicalThreadId08 combase!CoMarshalInterface09 combase!CoGetStandardMarshal0a combase!CoGetTreatAsClass0b combase!CoGetTreatAsClass0c combase!CoGetModuleArchitecture0d combase!CoGetTreatAsClass0e combase!CoGetTreatAsClass0f combase!CoCreateInstance10 combase!CoCreateInstance11 combase!CoCreateInstance12 netprofm!CPubINetworkListManager::GetPrivateNetworkListManager13 netprofm!CPubINetworkListManager::FinalRelease14 netprofm!ATL::CComObject<CPubINetworkListManager>::`scalar deleting destructor'15 netprofm!ATL::CComObject<CPubINetworkListManager>::Release16 NsBase10!Ns::OS::NetworkMonitor::_get17 NsBase10!Ns::OS::NetworkMonitor::get18 NsBase10!Ns::CloudStatusManager::subscribe19 NsPushNotifications10!Ns::PushNotificationManager::PushNotificationManager1a NsPushNotifications101b ucrtbase!initterm1c NsPushNotifications10!Ns::PushSubscriberEventSource::unsubscribe1d NsPushNotifications10!Ns::PushSubscriberEventSource::unsubscribe1e ntdll!LdrpCallInitRoutine1f ntdll!LdrpInitializeNode20 ntdll!LdrpInitializeGraphRecurse21 ntdll!LdrpInitializeGraphRecurse22 ntdll!LdrpInitializeGraphRecurse23 ntdll!LdrpInitializeGraphRecurse24 ntdll!LdrpInitializeGraphRecurse25 ntdll!LdrpInitializeGraphRecurse26 ntdll!LdrpInitializeProcess27 ntdll!_LdrpInitialize28 ntdll!LdrpInitialize29 ntdll!LdrInitializeThunk

Rest of the analysis is mostly identical to what Scott already mentioned.

I don't think we can work around this on our ends - its mostly a waiting for Autodesk / Microsoft situation.