M1 MacBook Pro crashes and restarts a few times a day

I have the same problem macbook pro 13 M1 chip. my mac crashes 2 times per day with a purple full screen . I HAVE NOTHING CONNECTED . ONLY USING SAFARI . its not a bluetooth or usbc hub problem . and not even a third party software . i contacted support many times did all they asked me to . SMC reset , full restore of Mac Os Big Sur . and all the usual crap apple support tells you to do when they have no answer . So until now Apple did not find a solution am afraid its an M1 problem

The trouble with your assessment, carlmurr, is that testing Big Sur on M1 hardware has been nearly the most tested configuration of all, if not the most tested!

When you performed a «full restore of Mac Os Big Sur», did that «restore» include restoring your software/utilities/etc.? Or was it a restoration to a “virgin” or “clean” state, without any third-party software/utilities/etc.?

You made some claim about «not even a third party software».

What, exactly, are you claiming?

(Many of the rest of us are using our M1 based Macs completely error free. Even with third-party software, and multiple printers [via AirPrint].)

However. If you are having such troubles on a completely “virgin” or “clean” system—completely devoid of any third-party software/utilities/etc., as well as any third-party hardware drivers (which can be downloaded and installed in the background, by the way)—then, your best course of action is, likely, to return your «macbook pro 13 M1 chip.»

I see you still have the «"busy timeout[0], (60s): 'AppleAPFSMedia'"», carlmurr.

This, as I wrote before, «suggests you have a filesystem problem. (It could even be Hardware related).»

Until the root cause, of this, is solved, you will continue to have this issue.

That’s rather odd, Rajesh Kanungo, but that isn’t a “crash” log of your system, but only of the Preview application:

«*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Invalid parameter not satisfying: !isnan(newSize.width)'

terminating with uncaught exception of type NSException

abort() called»

Something else must have happened.

You may need to find a different log.

Had another crash with Sony noise cancelling headphones (wh 1000 mx 3) directly connected to the MacBook Air m1 (no usb dongle) while having a video call over webex teams.

With an usb Headset everything is fine.

Thareesh wrote:

Yes, I have checked it. VS Code has released a Apple Silicon version. It isn't a compatibility issue as far as I know

It could still be a coding problem (which could be labeled as a “compatibility” issue, is some people’s “books”).

Make sure you keep up-to-date.

It could also be a compatibility issue with some other software: such as another Safari extension, or a system extension.

There are always a large number of programs running on a Mac (or any modern Operating System [OS]). Any compatibility issues of any such will lead to issues (often not easily traced to the actual culprit).

Even an installed driver, from attaching a third-party add-on hardware device (such as a hub, of some kind), just once, a while ago, can cause troubles, as we have seen. (This is especially true of non-Intel based Macs, since it takes time for the drivers, of such devices, to be upgraded for such a significant change.)

Very well, kjloope.

Microsoft should know what versions of Microsoft Office are compatible with Big Sur and M1.

(I had seen cases where people had «MS Office 2019» that were, quite obviously, incompatible: just because one has «MS Office 2019» does not guarantee—in and of itself—that one has a version thereof that is, indeed, compatible with Big Sur and M1.)

I hope you make sure you have such a version. It is Microsoft’s responsibility to produce a compatible version of their software. It is not Apple’s responsibility to attain or maintain any such compatibility.

Ultimately, it is your responsibility to choose what software you run on your machine.

Of course, none of this negates the fact that the Kernel Panic was caused by a Microsoft component.

My recommendation is for you to make sure of the compatibility of all the software you want to run on your machine. (No one else can do that for you.)

Just return it if you can. Going to Apple support is a waste of time as they will make you go through a data collection and debugging song and dance routine that can take days. There is no way a complex piece of hardware and software can be stabilized in the timeframe you are looking at.

Mine just crashes just sitting there. It reboots. Stays up for some random amount of time. Then crashes. I have become rather stoic about it as it does reboot really fast.

In this case, elip_aka, the problem was purely with Sketch!

«

Application Specific Information:

*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'NSApp with wrong _running count'

abort() called

terminating with uncaught exception of type NSException

»

Absolutely, AMXBOX. Apps shouldn’t be able to «trigger a reboot».

(However, kernel extensions, and other kernel level software, can, certainly, cause «reboot[s]» by way of kernel panics.)

switch to display port version 1.2

dont ask why, we don’t know exactly, just try it. report back how it goes :)

(before you say but it’s tb3! - we know - dp is used by tb to send the video signal)

You should not be using any AV with your Mac. If you do not remove it, you will have other issues down the road.

Yes, I have sent the crash reports in. It seems that Kodi is related to the problem. I haven't seen an app totally crash Mac OS in years and years. Triggering a reboot is practically unheard of these days.

For me, this started happening very consistently after the 11.1 update. Most frequently, it's com.apple.driver.AppleSEPManager that's the proximal cause for me.

2-3 crashes per day, every day, usually during important tasks or calls. May need to return the machine.

Rajesh Kanungo wrote:

… Apple is looking through my crash logs to determine the cause; no hub should crash an OS.

I absolutely agree: «no hub should crash an OS.»

Unfortunately, much USB equipment requires the installation of USB drivers.

If such drivers are running within the kernel, poorly written drivers can, certainly, cause kernel panics («crash an OS»).