Mountaineer
Read a jailbreak crash log with Mountaineer
Read a jailbreak crash log with Mountaineer: check the Timeline, distinguish memory kills from crashes, understand tweak hints, and send a useful report.
To read a jailbreak crash log with Mountaineer, open its Timeline after the problem, refresh, and select the matching entry. Start with the event classification and fault details, then use Copy Report to share what happened without turning a suspect-tweak hint into a definite accusation.
Read a jailbreak crash log from the Timeline
Mountaineer is our free crash diary for Dopamine rootless. It gives you a readable Timeline, fault hints, Doctor checks, and a Copy Report action.
Install com.carterware.mountaineer from the CarterWare source, https://tweaks.carterware.net/, in Sileo or Zebra. Free packages do not require an account.
After an unexpected crash or respring:
- Open the Mountaineer app.
- Open Timeline and pull to refresh.
- Select the entry that matches the event you just experienced.
- Read the event classification and faulting-frame details.
- Tap Copy Report to preserve the information for your support request.
Diary and App Shield controls live in Settings → Mountaineer. Reading an event in the app and changing those controls are separate actions, so begin with the entry before adjusting settings.
Mountaineer's listed requirement is iOS 15.0 or later on Dopamine rootless. We verified the crash Timeline, Shield on/off in TikTok, and Clear Diary across a respring on iOS 17.1 in version 1.4.8; that does not establish verification on every supported version.
Check whether the event was actually a crash
An unexpected return to the Home Screen or a respring is a symptom. The Timeline's classification helps you describe the event more precisely.
Mountaineer 1.4.10 added memory-kill entries for cases where iOS terminates SpringBoard or the foreground app for using too much memory. Those entries include peak memory in MB, and Copy Report gains a Memory line.
That release also distinguishes Userspace reboot from Unclean SpringBoard exit. Dopamine watchdog resets identify which daemon hung.
These distinctions matter when asking for help. A memory-kill entry gives you different evidence from a crashing stack with a suspect tweak. Copy the classification that appears rather than rewriting every event as “my jailbreak crashed.”
Intentional resprings have their own handling too. Version 1.4.8 fixed package-manager and sbreload resprings being labeled as unclean exits.
Version 1.4.9 then corrected a more specific case: a requested respring that crashed SpringBoard into Safe Mode could appear as intentional after leaving Safe Mode. It now appears as Respring didn't come back cleanly, flagged with how long ago the respring was requested.
The distinction is useful: requesting a respring and having it return successfully are not the same event.
Treat a suspect tweak as a lead
Mountaineer provides tweak-fault hints when a dynamic library looks involved. Those hints help focus a report, but the diary cannot invent a culprit when the evidence does not identify one.
We changed suspect selection in 1.4.7 so it comes from the crashing stack only. That fixed CarterWare being blamed for every crash. Version 1.4.8 also removed misleading titles that blamed Dopamine's own dyld, while 1.4.10 corrected older crash rows that showed the wrong type or blamed tweaks.
When reading an entry, keep three things separate:
- What you observed: the app closed, the screen changed, or the device resprang.
- What the entry classifies: a crash, memory kill, userspace reboot, or another recorded event.
- What the fault details suggest: a frame or library that may help explain the failure.
For example, if an app closes immediately after an action, describe that action first. Then include the event and its fault details. Do not replace the sequence with a claim that a particular tweak caused it unless you have established that separately.
This approach gives the developer evidence to investigate while preserving the uncertainty that still exists.
Keep App Shield separate from crash reporting
App Shield is another part of Mountaineer, with controls in Settings → Mountaineer. Its purpose is to help with third-party apps that object to jailbreak modifications.
Shield and path-hiding are best-effort. Mountaineer is not a Safe Mode replacement when SpringBoard is actively crashing.
The Hide jailbreak option also prevents other tweaks from loading into affected apps because their files are hidden. If a tweak stops working in an app after you enable that option, include the Shield setting in your report.
Version 1.4.11 narrowed hiding to real jailbreak locations so an app's own files would not disappear merely because their names contained a word such as “cydia.” Shield does not apply to system apps or apps installed by the jailbreak.
Keep system apps out of your Shield troubleshooting. Start by recording the settings you changed and the behavior before and after, so the developer can distinguish a crash from an intentional restriction on tweak loading.
If your issue is specifically ad blocking in one game, CarterBlock has its own Excluded Apps control. That control keeps CarterBlock out of the selected app; it serves a different purpose from reading Mountaineer's Timeline.
Send a report that can be followed
Once you have the matching entry, use Copy Report. Mountaineer puts “what happened” first, and the report includes details that help investigation.
For a Mountaineer problem, open Settings → Mountaineer → Report a Bug. Added in 1.4.12, this fills in the tweak version, iOS version, and iPhone model. Paste your Copy Report into the logs area.
Add a short sequence of actions:
- What you opened or changed before the event.
- What you expected to happen.
- What actually happened.
- Whether repeating the same action produced another matching entry.
Describe what you tried without inventing a test result. If the event happened only once, say so. If you changed Shield controls between attempts, include that change.
An empty Timeline usually means a quiet day; it does not supply evidence for naming a culprit. You can also use the website's Report a bug form when you need to contact us.
FAQ
Does Mountaineer prevent crashes?
No. It helps you understand recorded events and provides optional App Shield controls. It is not Safe Mode.
Can it tell me which tweak caused every crash?
No. It provides fault hints from the available evidence, and suspect selection uses the crashing stack. A hint is a starting point for investigation.
Is a memory kill the same as a normal crash entry?
Mountaineer distinguishes memory kills and includes peak memory information. Preserve that classification when sharing the report.
After the next unexpected event, open Mountaineer → Timeline, refresh, and copy the matching report before changing several settings at once. Send that report with the exact action you took so we can investigate the event you actually experienced.