PlatformIO on VSCode - Mac cannot shut down

Hi there.This text will be hidden
So I have this very strange issue with PlatformIO. It all started about a year ago when I installed PlatformIO the first time because I needed a customized firmware for my 3D printer.
Basically, the problem was that when I had PlatformIO installed in VS Code, my Mac wouldn’t shut down properly. Every time I tried shutting it down, a grey spinning wheel would show up, and after about 5 minutes, my Mac forcibly restarted and I got a Your system was restarted because of a problem popup. Resetting my Mac’s SMC/NVRAM didn’t help at all. But after some time I didn’t have time to mess around with my printer, so I uninstalled PlatformIO and everything worked just fine.
Fast forward, a few weeks ago I wanted to try out PlatformIO with one of my projects, and I noticed that again, my Mac wouldn’t shut down.
Now, I’m not much of an expert, but I’m thinking that maybe when I open VS Code (with PlatformIO installed and enabled), some program/process is executed by PIO and for some reason this process doesn’t terminate after closing VS Code, and it also doesn’t terminate when macOS tell it to do so (since the system is shutting down). So the OS has no choice but to crash. Although I could be totally wrong, and the problem is something else.

The only solutions I found so far are:

  • Temporary: Disable PlatformIO
  • Permanent: Uninstall PlatformIO

Steps to reproduce the issue:

  • Install PlatformIO in VS Code
  • Close VS Code
  • Shut down the Mac

I should also add that I’m using macOS Catalina 10.15.7 (19H1323). Also, after disabling PlatformIO, I have to let my Mac crash during a shutdown attempt (or just use the power button to forcibly turn it off), and only then I can open VS Code, use it, and shut down my Mac without it crashing.

Here’s a crash log:

panic(cpu 2 caller 0xffffff7f9c3a1aae): watchdog timeout: no checkins from watchdogd in 301 seconds (8 totalcheckins since monitoring last enabled), shutdown in progress
Backtrace (CPU 2), Frame : Return Address
0xffffff812eafbc40 : 0xffffff801b91c63d 
0xffffff812eafbc90 : 0xffffff801ba56b25 
0xffffff812eafbcd0 : 0xffffff801ba486ae 
0xffffff812eafbd20 : 0xffffff801b8c2a40 
0xffffff812eafbd40 : 0xffffff801b91bd07 
0xffffff812eafbe40 : 0xffffff801b91c0f7 
0xffffff812eafbe90 : 0xffffff801c0c0bc8 
0xffffff812eafbf00 : 0xffffff7f9c3a1aae 
0xffffff812eafbf10 : 0xffffff7f9c3a1486 
0xffffff812eafbf50 : 0xffffff7f9c3b6d9c 
0xffffff812eafbfa0 : 0xffffff801b8c213e 
      Kernel Extensions in backtrace:[BF2E24C6-42E3-3571-9159-8D230DF66A1B]@0xffffff7f9c3a0000->0xffffff7f9c3a8fff[F0FABEA7-41BA-36C9-8E53-9176C8440F2F]@0xffffff7f9c3a9000->0xffffff7f9c3c7fff

BSD process name corresponding to current thread: kernel_task
Boot args: chunklist-security-epoch=0 -chunklist-no-rev2-dev

Mac OS version:

Kernel version:
Darwin Kernel Version 19.6.0: Tue Jun 22 19:49:55 PDT 2021; root:xnu-6153.141.35~1/RELEASE_X86_64
Kernel UUID: EA37759C-12E3-3509-AD57-4B4A4FC5E7AD
Kernel slide:     0x000000001b600000
Kernel text base: 0xffffff801b800000
__HIB  text base: 0xffffff801b700000
System model name: MacBookPro16,3 (Mac-E7203C0F68AA0004)
System shutdown begun: YES

System uptime in nanoseconds: 370763370523
last loaded kext at 35922842306: com.wdc.kddfuse.filesystems.kddfuse	2053.16 (addr 0xffffff7f9fcce000, size 98304)
loaded kexts:
com.wdc.kddfuse.filesystems.kddfuse	2053.16
com.shinywhitebox.iShowU-Audio-Capture	1.0.5
>AudioAUUC	1.70
>!AGraphicsDevicePolicy	5.2.7
@fileutil	20.036.15
@AGDCPluginDisplayMetrics	5.2.7
>!AHV	1
|IOUserEthernet	1.0.1
|IO!BSerialManager	7.0.6f8
>!AUpstreamUserClient	3.6.8
>pmtelemetry	1
>AGPM	111.4.4
>!APlatformEnabler	2.7.0d0
>X86PlatformShim	1.0.0
>!A!IKBLGraphics	14.0.7
@Dont_Steal_Mac_OS_X	7.0.0
>AGDCBacklightControl	5.2.7
>!AThunderboltIP	3.1.4
>BridgeAudioCommunication	6.70.7
>ACPI_SMC_PlatformPlugin	1.0.0
>!ABacklight	180.3
>!AFIVRDriver	4.1.0
>!ABridgeAudio!C	6.70.7
>!AGFXHDA	100.1.429
>!A!IPCHPMC	2.0.1
>!AHIDALSService	1
>!A!ICFLGraphicsFramebuffer	14.0.7
>!AAVEBridge	6.1
>!A!ISlowAdaptiveClocking	4.0.0
>!AMCCSControl	1.14
@filesystems.ntfs	3.14.3
@filesystems.autofs	3.0
>!ATopCaseHIDEventDriver	3430.1
>usb.!UHostBillboardDevice	1.0
>usb.realtek8153patcher	5.0.0
@filesystems.apfs	1412.141.2
>BCMWLANFirmware4355.Hashstore	1
>BCMWLANFirmware4364.Hashstore	1
>BCMWLANFirmware4377.Hashstore	1
>!AFileSystemDriver	3.0.1
@filesystems.hfs.kext	522.100.5
@BootCache	40
@!AFSCompression.!AFSCompressionTypeDataless	1.0.0d1
@!AFSCompression.!AFSCompressionTypeZlib	1.0.0
>!AVirtIO	1.0
>!A!BModule	1
@private.KextAudit	1.0
>!ASmartBatteryManager	161.0.0
>!ABCMWLANBusInterfacePCIe	1
>!AACPIButtons	6.1
>!AAPIC	1.7
$!AImage4	1
@nke.applicationfirewall	303
$TMSafetyNet	8
@!ASystemPolicy	2.0.0
|EndpointSecurity	1
>!AGraphicsControl	5.2.7
|IOAVB!F	850.1
>usb.cdc.acm	5.0.0
>usb.serial	6.0.0
>!AHDA!C	283.15
|IOHDA!F	283.15
@!AGPUWrangler	5.2.7
>IOPlatformPluginLegacy	1.0.0
>!ABacklightExpert	1.1.0
>!AActuatorDriver	3440.1
>!AThunderboltEDMSink	4.2.3
>!AThunderboltDPOutAdapter	6.2.6
|IONDRVSupport	576.1
>!A!ILpssUARTv1	3.0.60
>!A!ILpssUARTCommon	3.0.60
>!AOnboardSerial	1.0
>!ASMBusPCI	1.0.14d1
@!AGraphicsDeviceControl	5.2.7
|IOAccelerator!F2	438.7.4
|IOSlowAdaptiveClocking!F	1.0.0
>X86PlatformPlugin	1.0.0
>IOPlatformPlugin!F	6.0.0d8
>!ASMBus!C	1.0.18d1
|IOGraphics!F	576.1
>!AHIDKeyboard	209
@plugin.IOgPTPPlugin	840.3
|IOEthernetAVB!C	1.1.0
@kext.triggers	1.0
>!AMultitouchDriver	3440.1
>!AInputDeviceSupport	3440.8
>!AHS!BDriver	3430.1
>IO!BHIDDriver	7.0.6f8
>usb.IOUSBHostHIDDevice	1.2
>usb.cdc.ecm	5.0.0
>usb.cdc.ncm	5.0.0
>usb.!UHub	1.2
>usb.cdc	5.0.0
>usb.networking	5.0.0
>usb.!UHostCompositeDevice	1.2
>!AXsanScheme	3
>usb.!UVHCIBCE	1.2
>usb.!UVHCI	1.2
>usb.!UVHCICommonBCE	1.0
>usb.!UVHCICommon	1.0
>!AEffaceableNOR	1.0
|IOBufferCopy!C	1.1.0
|IOBufferCopyEngine!F	1
|IONVMe!F	2.1.0
>!AThunderboltPCIDownAdapter	2.5.4
>!AThunderboltDPInAdapter	6.2.6
>!AThunderboltDPAdapter!F	6.2.6
>!AHPM	3.4.4
>!A!ILpssI2C!C	3.0.60
>!A!ILpssDmac	3.0.60
|IOSurface	269.11
@filesystems.hfs.encodings.kext	1
|IOAudio!F	300.2
@vecLib.kext	1.2.0
>!AThunderboltNHI	5.8.6
|IOThunderbolt!F	7.6.1
>IO!BHost!CPCIeTransport	7.0.6f8
|IO!BHost!CTransport	7.0.6f8
>!A!BDebug	1
>!AConvergedIPCOLYBTControl	1
>!A!BDebugService	1
>!AConvergedPCI	1
>usb.!UHostPacketFilter	1.0
|IOUSB!F	900.4.2
>!A!ILpssI2C	3.0.60
>usb.!UXHCIPCI	1.2
>usb.!UXHCI	1.2
>!A!ILpssGspi	3.0.60
>!AEFIRuntime	2.1
>!AMultiFunctionManager	1
>!ABCMWLANCore	1.0.0
>mDNSOffloadUserClient	1.0.1b8
>IOImageLoader	1.0.0
|IOSerial!F	11
|IO80211!FV2	1200.12.2b1
>corecapture	1.0.4
|IOSkywalk!F	1
|IOSMBus!F	1.1
|IOHID!F	2.0.0
$quarantine	4
$sandbox	300.0
@kext.!AMatch	1.0.0d1
>!AKeyStore	2
>!UTDM	489.120.1
|IOSCSIBlockCommandsDevice	422.120.3
>!ACredentialManager	1.0
>!AFDEKeyStore	28.30
>!AEffaceable!S	1.0
>!AMobileFileIntegrity	1.0.5
@kext.CoreTrust	1
|CoreAnalytics!F	1
|IOTimeSync!F	840.3
|IONetworking!F	3.4
>DiskImages	493.0.0
|IO!B!F	7.0.6f8
|IO!BPacketLogger	7.0.6f8
>!ASSE	1.0
>KernelRelayHost	1
>!ASEPManager	1.0.1
>IOSlaveProcessor	1
|IOUSBMass!SDriver	157.140.1
|IOSCSIArchitectureModel!F	422.120.3
|IO!S!F	2.1
|IOUSBHost!F	1.2
>usb.!UCommon	1.0
>!UHostMergeProperties	1.2
>!ABusPower!C	1.0
|IOReport!F	47
>!AACPIPlatform	6.1
>!ASMC	3.1.9
>watchdog	1
|IOPCI!F	2.9
@kec.pthread	1
@kec.corecrypto	1.0
@kec.Libm	1
1 Like

I’m kinda baffled how a VSCode extension can cause something like a kernel panic or a watchdog timeout in this case so deep in the operating system, at all. You can try opening an issue at Issues · platformio/platformio-vscode-ide · GitHub for this, that’s a better place than here for bug reports.

Yeah, I’d like to know what’s going on too. I opened an issue on GitHub.

FWIW, I’ve been bitten by kernel hangs as well as panics on MacOS due to problems with USB - especially with FTDI serial port drivers. So that’s where I’d look …

I really don’t think that this is related to FTDI serial port drivers.

  1. Like I said, to “trigger” this issue all I have to do is open VS Code with PIO installed, no boards plugged in (AFAIK macOS will not load the serial drivers until the device is plugged in).
  2. Before PIO, I was programming all kinds of development boards (in Arduino IDE), a lot of them were using questionable FTDI chips and their drivers were also very outdated, yet I never had any kernel panics/crashes/etc. It was all fine for a very long time.

Yeah, I think you’re right. Must be something else.

But I do want to point out that the FTDI problems were new. Years ago, I never had issues with FTDI either. It all started after one of the newer macOS releases. I no longer use/need FTDI - it’s almost all ST-Link and Black Magic Probe for me these days.

Maybe it helps:
I had the same problem. MacBookPro 2013, Big Sur 11.6.1. The same error (hanging during shutdown, automatic restart after around 300 secs, the same error message.
When Kernel is hanging, look first for third party Kernel extensions.
In your case:
loaded kexts:
com.wdc.kddfuse.filesystems.kddfuse 2053.16
com.shinywhitebox.iShowU-Audio-Capture 1.0.5

In my case:
also com.wdc.kddfuse.filesystem.kddfuse but with version 2053.20.
No other 3rd party Kernel extensions loaded.
This Kernel extension is needed, as the Western Digital home file system is KDDFS. So looks like you are also using WD e.g. for My Cloud Home? (Just for a TimeMachine backup on WD, you wouldn’t need the Kernel extension).
In my case, I had in the WD Discovery the automatic start at system startup enabled. So the WD Kernel Extension was automatically loaded (and visible with kextstat in terminal as the only 3rd party Kernel extension. After disabling it, the shutdown works normal (but only after the second shutdown-restart, maybe because I was doing any reset).
So your problem could be also related to the WD Kernel extension.
Only thing, which irritates me, is, that in your crashreport, the WD kernel extension is not only showing up as a loaded kext, but also as the last loaded Kernel extension, so looks like you are not starting your WD Discovery automatically, but manually, so maybe not regularly? So not shure whether my solution works for you. But worth not to start WD, and ensure, that the WD Kernel extension is not loaded (check with kextstat) for some days. If problem continues, and the crashreport is not containing the WD kernel extension, look for your other third party kernel extension (shinywhitebox) as a potential source of Kernel issues.

Oh my god. Yess. I am using the WD Discovery app.
I turned off automatic startup after I started using it, and whenever I needed to access my WD My Cloud Home, I just started the app and then when I was done, I closed it.
However, I have noticed that upon startup the WD Discovery app would start up (it appeared in the dock) and after a second or two, it would close. Not sure why. WD probably coded it such that it starts up always and then if autostart was disabled, it would quit. Quite a dumb way to implement autostart controls, but whatever. A few months ago I managed to completely disable it by using CleanMyMac. Now it doesn’t start up at all. Since then, I haven’t tried PlatformIO. I’ll check tomorrow if this shutdown issue is fixed.
Even if this does fix the issue, it probably means that after using the WD Discovery app I will have to restart my Mac, which is going to be a bit annoying. I’ve been thinking about getting a new NAS, but currently I don’t have a budget for a new one, so I’m kinda stuck with what I have for a while. :roll_eyes:
I am curious though, what does PlatformIO have to do with the KDDFS kext? There has to be a connection, since disabling PlatformIO fixes the issue.

Seems like very recently someone has posted about this in New 5TB WD drive crashes my mac - External Drives for Mac - WD Community and WD Discovery is not working on M1 / Apple Silicon MacBook Air - #97 by forthehandyman - My Cloud Home - WD Community too.

Can you write the technical support a ticket per