We have added a diagnostic event to the Macrium Image Guardian (MIG) driver that will write a “stack trace” to the System Event Log when a file operation that originated in the unnamed system process is blocked by MIG.
The event lists (in reverse order) the entry point address of the functions that were invoked leading up to (and including) the blocked file operation. Each entry shows the virtual address of the function and the name of the module in which the function resides.
The following screenshot shows where gemma.sys (a component of BitDefender) issued a request to open a Macrium Reflect image file for writing and was blocked.
The next screenshot shows where a file operation that originated on a remote PC was blocked. Here we can see that the srv2.sys (Microsoft SMB 2.0 Server) driver made the request on behalf of the remote process.
Unless there are no other modules listed, the NTOSKRNRL.EXE (Windows OS Kernel) and FLTMGR.SYS
(Windows Filter Manager) module can safely be ignored. These modules are part of the Windows operating
system and provide basic services to applications and device drivers.
Likewise, MRIGFLT.SYS will always appear at the top of the list and can safely be ignored. This simply indicates
which MIG function blocked the file operation.
In most instances, the listed modules can be found in the \Windows\system32 or \Windows\system32\drivers
folders. Inspecting the properties for the module will allow you to determine the author of the module and
which product it belongs to.
Additionally, there are various websites that maintain databases of common modules along with details such
as author, digital signature information, file hashes, etc. These can normally be accessed by simply
searching for the module name online.