Home labs & practical projects

Analyse a training-program crash reproducibly

A project to do with your own tools, with guidance on what to create and capture.

Local lab Suggested time: 3–4 hoursYour own authorised environment

What you could create

A deliberately faulty educational program crashes on a malformed input. The task is to understand the failure and communicate a defensive fix.

Example evidence format

Project evidence map (example)

Crash analysis with source referencesScope and inputs

Defensive fix and regression resultsDecisions and reasoning

Evidence record (example)

Evidence	What to capture
Crash analysis with source references	Show the inputs, scope and decisions behind this record. The report includes enough build context to reproduce the defect.
Defensive fix and regression results	Include the evidence supporting your conclusion. The patched program handles the input safely without suppressing all errors.

What you'll need

Local lab

Use a benign local training program, debugger and disposable VM. Keep the original source, build options and triggering test input.

Project record

Keep the working files for crash analysis with source references and record assumptions as you go.

Current reference material

Use the linked provider resources to verify the features, access terms and version relevant to your project.

Access & cost

Uses your own computer. Confirm hardware capacity, software licences and download terms before setup.

Use disposable VMs, containers or a simulator. Keep the lab separate from your everyday machine and work network.

Suggested milestones

1
Plan and investigate
Reproduce the crash and record the program state at failure.
2
Develop your approach
Trace the input-handling defect and explain relevant memory-safety assumptions.
3
Verify and explain
Propose a fix and rerun normal, boundary and malformed test cases.

Evidence worth keeping

Keep clear, organised evidence of your design and any testing you carry out.

1
Crash analysis with source references
Show the inputs, scope and decisions behind this record. The report includes enough build context to reproduce the defect.
2
Defensive fix and regression results
Include the evidence supporting your conclusion. The patched program handles the input safely without suppressing all errors.

Label design proposals and observed results clearly.

Explain your work

Use these prompts to reflect on your decisions and what you learned.

Which part of your crash analysis with source references needed the most judgement?
What observation or assumption changed your approach?
What would you improve, and what have you not verified?

Describe this as a personal project in your portfolio.

Useful resources

Use these resources to deepen your understanding and check key details.

Official certification objectives

Review the current provider requirements and relevant subject areas.

Explore external learning resources

Find relevant providers and check features, access requirements and costs.

A useful starting point

Use a benign local training program, debugger and disposable VM. Keep the original source, build options and triggering test input.

What a good result looks like

The report includes enough build context to reproduce the defect.
The patched program handles the input safely without suppressing all errors.

Finish the project

Save sanitised evidence, then remove the lab instances or revert to the clean snapshot. Remove temporary accounts and credentials.

Independent home-project guidance, not an official vendor lab or a claim of complete exam coverage. Use your own tools and label the work accurately.