Mac freezes after waking with the VPN: what to record

Reports of a frozen Mac after a wake often merge three failures into one complaint. The pointer may still move while the VPN client ignores clicks, the client may work while a single remote session times out, or the whole desktop may stop taking input. Each of those needs different evidence, and the first minute after the freeze decides which one you are looking at. Guessing wrong sends every later step in the wrong direction.

What stopped answering, and what only stopped waiting

Run the cheapest tests first: move the pointer and type into a local text field, open the client's own status view and read the state it reports, then start a fresh operation in the private application instead of resuming the session that was already open. Write the three answers down before you touch anything else, because the order of what failed is the first detail people forget.

Each outcome points somewhere different. A single stuck session puts the evidence on the far side of the tunnel, and the Mac is only a bystander. A client that ignores clicks while the desktop still works narrows the search to that process and its log. A machine that ignores the pointer removes the option of running anything at all, since every inspection command needs a shell that answers.

Keep the three cases separate even when the user describes them with one sentence. The report you file should say which test failed first and which ones still passed, not that the machine froze. That distinction is what lets a support engineer decide whether to look at the network, the client or the hardware.

A timeline you can still defend tomorrow

The clock is the part of the record that cannot be rebuilt later. Note when the lid opened or the machine woke, when the first failed action happened, and whether those two moments were seconds or minutes apart. Then write down whether the Mac truly slept or only locked its screen, because those are different states with different wake paths. The sleep log is the only part of that timeline you can check afterwards.

pmset -g log | grep -i -E 'wake|sleep'
log show --last 15m --predicate 'process == "<client-process>"' --style compact

The first command turns a vague memory into a timestamp you can type into the second. Limit the log query to the client process and a short window, and you get a page of output instead of a day of it. Copy the model identifier, the client build and the network you were on into the same note while the screen is still in front of you; a report assembled the next morning loses the ordering that made it readable.

Pick the capture that matches the symptom

Apple documents three captures in its Activity Monitor diagnostics guide, and they answer different questions. Sample Process watches one selected process for three seconds, spindump targets an application that has stopped responding and is about to be force quit, and System Diagnostics collects system logs into a bundle.

Choose by what you observed rather than by habit. A client that runs but misbehaves gets a sample, taken with sample <pid> 3 -file ~/Desktop/sample.txt or from the gear menu. An app that spins forever and has to be killed gets the Spindump item from that same menu. A problem that spans the client and the system gets sudo sysdiagnose -f ~/Desktop. Sample before you force quit when you can, because termination destroys exactly the state you wanted to inspect, and name the file after the event and the time rather than after your guess about the cause.

Treat every bundle as sensitive. These reports carry account names, hostnames, paths and network details, so send them through the support channel your organisation uses instead of attaching them to a public thread. If a report has to be trimmed, trim a copy and keep the original intact.

When the pointer itself will not move

A dead interface changes the order of operations. You cannot sample a process or run a query from a shell that does not answer, so the first goal is recovery and the second is a record. A forced restart is sometimes the only way out, and it is also the moment when the most useful details disappear. Note the time, the windows that were open and whether the network menu showed a connection before you restart; those observations survive the reboot even though the process state does not.

After the machine is back, resist the conclusion that the restart found the culprit. It restored service and named nothing. Only a repeat with one controlled change can point at a component.

If the freeze returns, alter one condition per attempt: the network, the client version, or the sleep mode. Save remote work first, and avoid looping forced sleeps on a production machine, since repeated hard cycles risk data loss and often produce a different failure than the one you are chasing. Write each attempt down with its conditions so the next one is comparable rather than anecdotal.

Hand off one event, not a mood

The handoff that gets action names four things: what stopped responding, when it happened, what the network looked like at that moment, and which capture covers the window. Add the client version and the macOS build, then stop. Both the platform team and the client vendor can act on that sentence, and neither can act on a description of frustration. Keep the record in one place and append to it instead of retelling the story each time; if an update changed the behaviour, note which update, because that is evidence too.

A good record also states what you already ruled out. If a local application answered during the freeze, say so; if the sleep log shows a real wake rather than a lock, say that as well. The next person should not have to repeat tests you have already run.

Before you close the ticket, check three things: the timestamp comes from the sleep log rather than memory, the capture matches the symptom you actually saw, and the bundle sits in the approved location. If any of the three is missing, the report is not ready to send.