Debugging usvfs

Logs

Enabling debug logs in MO does the same for usvfs. Although most calls get logged, some logs are skipped if the object did not end up being redirected. DeleteFile(), for example, won't log anything if the file was not redirected. This avoids flooding the logs with stuff that's typically irrelevant, but can hide some problems.

Most log lines are in the format timestamp <pid:tid> [L] message [param] [param]....

Example:

07:52:53.161 <19328:40984> [D] hook_GetFileAttributesW [lpFileName=\??\C:\skyrim\data\] [reroute.fileName()=C:\mo\overwrite] [res=10] [originalError=0] [fixedError=0]

Description of the various parts (note that the parameters are specific to GetFileAttributesW(), this is just an example):

Part	Description
07:52:53.161	Local time of the message.
<19328:40984>	Process ID is 19328, thread ID 40984. The process ID is useful because more than one process might be running under usvfs.
hook_GetFileAttributesW	All the usvfs hooks start with hook_ and contain the original function name.
lpFileName=\??\C:\skyrim\data\	The original filename passed by the process.
reroute.fileName()=C:\mo\overwrite	The redirected filename that usvfs ended up using instead.
res=10	Return value of underlying call to GetFileAttributesW(); in this case, attribute bits.
originalError=0	Result of GetLastError() immediately after the call.
fixedError=0	Same as originalError but with some errors remapped (ERROR_PATH_NOT_FOUND -> ERROR_FILE_NOT_FOUND, etc.)

Delay

MO can keep the process suspended for some time after starting it. This is useful for attaching a debugger or resetting procmon. It's a hidden setting in the INI:

[Settings]
spawn_delay = X   # in seconds

Process monitor

Download from sysinternals. Add a filter for the target process and make sure "Show File System Activity" is toggled in the toolbar. This will show every filesystem call and can be used the complement the logs.

Debugger

An instance of Visual Studio that has the usvfs solution opened can attach to any process that was spawned directly or indirectly by MO. Adding a delay makes this much easier.

• Debug/Attach to Process...
• Double-click on the target process in the list

After that, breakpoints can be added, the process can be paused, etc.

When debugging processes that spawn children, the Child Process Debugging Power Tool extension can be used. It treats all the children as one large process in terms of debugging, so breakpoints will be hit by any of them.