GCFA Introduction to Memory Forensics Practice Question
An examiner is analyzing a Windows memory image and wants to determine whether a specific kernel driver was loaded and then unloaded during the system's uptime. Which approach is most appropriate?
⚠ Common exam trap
The trap here is relying on the current module list or registry configuration to answer a historical question about whether a driver was ever loaded.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Search for the driver's pool tags and compare them against the current loaded module list to identify remnants of an unloaded driver.
Pool tags and residual pool allocations can persist after a driver unloads, so searching for a driver's known pool tags and comparing against the current module list can reveal that it was loaded earlier. The module list itself only shows current modules, registry keys show configuration, and event logs are not reliable for this purpose in memory forensics.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Check the system event log for a service control manager entry indicating the driver was started.
Why it's wrong here
Event logs may record service start events, but memory forensics focuses on in-memory artifacts, and event logs in a memory image are often incomplete or volatile. Relying on event logs does not directly answer whether a driver was loaded and unloaded, and the logs may not capture driver load events at all, especially for kernel drivers loaded outside service control manager.
- ✓
Search for the driver's pool tags and compare them against the current loaded module list to identify remnants of an unloaded driver.
Why this is correct
Unloaded drivers can leave pool allocations and pool tags in memory even after their module entry is removed. Searching for the driver's known pool tags and comparing against the current module list can reveal remnants indicating the driver was present earlier. This technique leverages memory artifacts that persist beyond the driver's active lifetime, providing evidence of prior loading.
- ✗
Examine the registry hives in memory for the driver's service key and confirm its start type.
Why it's wrong here
Registry service keys show configuration, such as whether a driver is set to load at boot, but they do not reveal whether it was actually loaded during the current uptime. A driver can be configured but never started, or started and later stopped, and the registry would look the same. This method addresses configuration, not runtime loading history.
- ✗
Run windows.modules and check whether the driver appears in the output.
Why it's wrong here
windows.modules lists currently loaded modules by walking PsLoadedModuleList. An unloaded driver would no longer appear in that list, so its absence does not prove it was never loaded. This approach cannot distinguish between a driver that was never present and one that was loaded and later removed, making it insufficient for the examiner's question.
About these practice questions
This GCFA question is part of Courseiva's 292-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official GIAC exam blueprint
This GCFA practice question is part of Courseiva's free GIAC certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the GCFA exam.