Fusion360 won't start on latest Windows 10 Insider build (19030)

Anonymous · ‎11-22-2019

OS Name: Microsoft Windows 10 Pro
OS Version: 10.0.19030 N/A Build 19030

Attempt to start program, it will freeze and never get to the splash screen. I'm available to grab whatever info you need from the process, since it doesn't die. It's just hanging.

Anonymous · ‎12-06-2019

Is there anyone on this build not having an issue?

gmccauley · ‎12-06-2019

Just came to add a +1 to build 19033.1

Anonymous · ‎12-06-2019

Tried to post some info in another thread, but got marked as spam 😕

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:

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 showed that there are no threads listed for 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 · ‎12-06-2019

Issue is ALPC communications from Fusion360. I tried to post a call stack/ALPC debug into but it got marked as spam.

LPC_REQUEST is being sent and processed by svchost (responsible for RPCSS), and in turn svchost is sending an LPC_CONNECTION_REQUEST back, but there is no service/thread hooked up to receive that message.

ycahome · ‎12-07-2019

Hello, +1.

I hope that posting "me too" or "+1" has an added value and someone see the impact.

Also, i have submitted a problem feedback on Microsoft insider's Feedback app (with a problem recording). You can vote it on the following link.

https://aka.ms/AA6r0o7

Maybe its good to add this link to the very first post. Microsoft process the most up-voted feedback faster.

br,

Anonymous · ‎12-07-2019

same problem with Windows 10 Insider Preview 19037.1 (vb_release)

slickmilwaukee · ‎12-07-2019

I just did the same. Hope it helps.
If Autodesk/Microsoft do not address this issue, and this gets pushed to production, it will damage the entire brand. I sure hope someone is listening. Seems like we're screaming into the void here.

StarNamer · ‎12-07-2019

There are multiple threads about this issue and several Autodesk support staff have replied on them.

From a support standpoint (i.e. get the user working again), the recommendation is to revert to an earlier build of Windows, ideally the released version.

From a development standpoint (i.e. fix the problem), they are working on it and are happy to receive details you think may help. I've seen one reply where a user has obviously tracked interprocess calls to help isolate the issue. Obviously a fix could take some time.

Microsoft always advise that the Insider Preview not be used on 'production' machines and Autodesk obviously can't anticipate if an Insider Preview change might break something but I am confident are working, probably in communication with Microsoft, to fix the issue in Fusion 360 before whatever the change is gets released as a final version.

jarnoburger · ‎12-07-2019

me too.

plz send me gummy bears to keep calm..

Anonymous · ‎12-08-2019

Same here with build 19037

Anonymous · ‎12-08-2019

Same here, 19037. Rollback not possible because too far out of the rollback windows.

Really need a fix here autodesk.

Anonymous · ‎12-09-2019

Difficult to understand why Autodesk do not correct this major bug quickly. Because it is certainly quite easy to fix (with the code !). Not very encouraging for professional users that would want to switch to Fusion 360.

slickmilwaukee · ‎12-09-2019

Same action on Build 19037.1

ambillyNKVSQ · ‎12-09-2019

Samer issue here

The insider hub shows tons of similar issues...

StarNamer · ‎12-09-2019

How do you know it's "easy to fix (with the code !)"? I assume you haven't looked at it and identified a fix or you'd already have posted it to Autodesk.

It may be that Microsoft's change breaks the program logic in such a way that a significant rewrite is needed. I've been programming for nearly 40 years and had that happen a few times. Annoyingly, at least once, we fixed our code, only to have the change reversed at a later date when they realized that it broke applications.

Also, professional users are unlikely to be running production work on a Windows Insider Preview version as Microsoft themselves recommend against this.

andyNY4FG · ‎12-09-2019

Exactly. Autodesk are aware of the issue, and I'm sure they're working on a fix, it just isn't a priority because those of us on the Windows Insider preview builds are in the minority of Fusion 360 users. Remember, when we signed up to Inside builds, we knew that running pre-release versions of Windows might break something - and that's why we do it, so that the issues we experience aren't rolled out to the wider Windows user base (although, based on some of Microsoft's recent updates, I'm not sure whether the process is working!). Both Microsoft and Autodesk are aware that something's borked in the latest update, so it will get fixed, but these things take time.

I don't think posting any more "me too" messages is going to help either - Autodesk know about this, adding your name to the list isn't going to speed things up any.

I also think that when a fix does come, it'll probably mean that we'll have to re-install Fusion because the current version can't start properly to get any updates meaning that the only way to get updates is to download a new version from scratch.

Anonymous · ‎12-09-2019

>it just isn't a priority because those of us on the Windows Insider preview builds are in the minority of Fusion 360 >users
I think this is why a lot of people should write "me too" ! To show they are more numerous than Autodesk thinks.

And Autodesk should thanks Windows insider users because without them it would have been 100% of Fusion 360 users that could not work anymore when the beta Windows would have became an official version. Not correcting quickly the problem means Windows Insider will stop being insiders so free beta testers...

Anonymous · ‎12-09-2019

I program for 25 years and most of the time such bug is quite easy to repair if we try to. And if all rogram infrastructure has to be modified because of Microsoft change in Wiondows, it means the programmation of Fusion is very very bad, with a big mistake made (with a Microsoft standard not respected). In fact it is very probable that the start problem is related to copyright protection that like everytime annoys only regular users and not pirates.

Anonymous · ‎12-09-2019

This is probably the same issue i'm having then

slickmilwaukee · ‎12-09-2019

Seems to be across the board. Fusion 360 itself is a program and ecosystem that would require an 'Insiders Program' mindset to try and adopt, especially in a professional environment.

My personal Windows is IP, but our companies' copies are on the standard Windows release platform. My purpose is to understand what's in the pipeline and be prepared for it when it hits production, good or bad.

If Autodesk does not listen, they will lose us as a resource.

I literally googles Solidworks Cam this morning - There is no way we can risk going hard-down like this. We just can't.

Community

Fusion360 won't start on latest Windows 10 Insider build (19030)

Fusion360 won't start on latest Windows 10 Insider build (19030)

Fusion360 won't start on latest Windows 10 Insider build (19030)