13.3 update messes up the sleep function of M1 MBP 13"

[YS2015]

After 13.3 update, my M1 macbook pro 13" stops responding when I put it to sleep manually. After about 30 seconds of that frozen state, it crashes and reboots. Also, when the MBP goes to sleep, it will crash. The set up for my MBP is exactly the same and this sleep crash started everytime after 13.3 update. 13.3.1 update did not fix this problem.

Has anyone experienced the similar issue with 13.3 update?

The first portion of the typical crash report is shown below:

Process: WindowServer [-1]
Path: ???
Identifier: WindowServer
Version: ???
Code Type: 00000000 (Native)
Parent Process: ??? [Unknown]
User ID:

Date/Time: 2023-04-14 21:26:09.1385 +0900
OS Version: macOS 13.3.1 (22E261)
Report Version: 12
Anonymous UUID: 8F96E25C-3F2C-1E9F-0DB7-5F5B32B6BF10



System Integrity Protection:

Notes:
resampled 151 of 2875 threads with truncated backtraces from 0 pids:
resampled 0 of 21 images missing from 47 pids: 128,161,365,395,400,412,415,418,419,422,428,429,465,511,516,519,523,534,563,568,629,665,669,684,693,695,698,725,737,740,755,756,819,820,821,822,823,829,1944,1945,1946,1947,1967,2070,3016,4045,4140
17 unindexed user-stack frames from 13 pids: 128,412,422,568,599,620,665,669,695,698,764,820,4140
This is a watchdog-triggered termination event, and not expected to be well-represented in the legacy crash format

Crashed Thread: Unknown

Exception Type:

Termination Reason: Namespace WATCHDOG, Code 1 monitoring timed out for service
(1 monitored services unresponsive): checkin with service: WindowServer returned not alive with context:
unresponsive work processor(s): WindowServer main thread
40 seconds since last successful checkin, 5628 total successful checkins since 56380 seconds ago (0 induced crashes), has not exited since first loaded

 

[HDFan]

1. Does this happen if you login as a test user?

2. Does it happen in Safe Mode?

 

[YS2015]

1. Does this happen if you login as a test user?

2. Does it happen in Safe Mode?

I have only 1 user I had set up at the time of the delivery of this mac and I have not changed anything on this MBP from the beginning. I have not used it in safe move. But, I have run the diasnostics mode (the one you can get into by pressing Command + D).

 

[YS2015]

I have activated the "guest" account and logged in as "guest" to see what happens when I manually put the mac into "sleep" from the top left corner of Apple mark pull down menu. The outcome is exactly the same as the mac stops responding for about 30 seconds (or more) and crashes and restarts.

 

[TheLivingTree]

I am having the same issue on the same os version (OS Version: macOS 13.3.1 (22E261)).

I also had this issue back with Monterey. At the time, I just had to wait and eventually upgrade to Ventura to fix the crashing. Back then, I tried a guest user and reinstalling the version in safe mode to no success.

Sorry this is not a very hopeful reply but I will post again if I discover anything.

Here is my crash report:

Spoiler: Report

panic(cpu 1 caller 0xfffffff0287afa68): macOS panic detected
Debugger message: panic
Memory ID: 0x6
OS release type: User
OS version: 20P4252
macOS version: 22E261
Kernel version: Darwin Kernel Version 22.4.0: Mon Mar 6 19:59:22 PST 2023; root:xnu-8796.101.5~1/RELEASE_ARM64_T8010
KernelCache UUID: CED28ACE5130367D402E135444FBB735
Kernel UUID: F1917FD8-2F88-39FB-8CCA-40A668D190BA
Boot session UUID: 0A922EB5-6E8C-49E2-982F-3D72A56D137F
iBoot version: iBoot-8422.100.650
secure boot?: YES
roots installed: 0
x86 EFI Boot State: 0x16
x86 System State: 0x0
x86 Power State: 0x0
x86 Shutdown Cause: 0xf5
x86 Previous Power Transitions: 0x70604000100
PCIeUp link state: not available
macOS kernel slide: 0x17e00000
Paniclog version: 14
Kernel slide: 0x000000002247c000
Kernel text base: 0xfffffff029480000
mach_absolute_time: 0x1bdd08e4b8
Epoch Time: sec usec
Boot : 0x644287e7 0x00044f39
Sleep : 0x64429c00 0x00061402
Wake : 0x00000000 0x00000000
Calendar: 0x64429c00 0x0007681d

Zone info:
Zone map: 0xffffffddd3bfc000 - 0xffffffe3d3bfc000
. VM : 0xffffffddd3bfc000 - 0xffffffdeba260000
. RO : 0xffffffdeba260000 - 0xffffffdf06f2c000
. GEN0 : 0xffffffdf06f2c000 - 0xffffffdfed590000
. GEN1 : 0xffffffdfed590000 - 0xffffffe0d3bf4000
. GEN2 : 0xffffffe0d3bf4000 - 0xffffffe1ba25c000
. GEN3 : 0xffffffe1ba25c000 - 0xffffffe2a08c4000
. DATA : 0xffffffe2a08c4000 - 0xffffffe3d3bfc000
Metadata: 0xffffffdc0b0cc000 - 0xffffffdc0c8cc000
Bitmaps : 0xffffffdc0c8cc000 - 0xffffffdc0c9f8000
Extra : 0 - 0

TPIDRx_ELy = {1: 0xffffffdfed6f6ba8 0: 0x0000000000000001 0ro: 0x0000000000000000 }
CORE 0: PC=0xfffffff0285d9a14, LR=0xfffffff0285d9a08, FP=0xffffffe58be77e40
CORE 1 is the one that panicked. Check the full backtrace for details.
Compressor Info: 0% of compressed pages limit (OK) and 0% of segments limit (OK) with 0 swapfiles and OK swap space
Panicked task 0xffffffe2a081c5d0: 0 pages, 230 threads: pid 0: kernel_task
Panicked thread: 0xffffffdfed6f6ba8, backtrace: 0xffffffe58c063700, tid: 456
lr: 0xfffffff02967184c fp: 0xffffffe58c063770
lr: 0xfffffff029791cfc fp: 0xffffffe58c0637e0
lr: 0xfffffff029790cbc fp: 0xffffffe58c0638c0
lr: 0xfffffff0296355fc fp: 0xffffffe58c0638d0
lr: 0xfffffff029671288 fp: 0xffffffe58c063c80
lr: 0xfffffff029cbf634 fp: 0xffffffe58c063ca0
lr: 0xfffffff0287afa68 fp: 0xffffffe58c063cd0
lr: 0xfffffff028797604 fp: 0xffffffe58c063d30
lr: 0xfffffff0287a0aec fp: 0xffffffe58c063d80
lr: 0xfffffff028799b5c fp: 0xffffffe58c063e20
lr: 0xfffffff028796b94 fp: 0xffffffe58c063e90
lr: 0xfffffff0285acb40 fp: 0xffffffe58c063ec0
lr: 0xfffffff029c105bc fp: 0xffffffe58c063ef0
lr: 0xfffffff029c0feac fp: 0xffffffe58c063f20
lr: 0xfffffff0296406c0 fp: 0x0000000000000000

 

[YS2015]

@TheLivingTree
Thanks for sharing your situation. For some reasons, I knew my sleep-crash problem is affecting many others as this started exactly after 13.3 update. Your reply above confirmed my assumption. I strongly believe there is something buggy about 13.3 updates.