Debugging usvfs - ModOrganizer2/modorganizer GitHub Wiki
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.) |
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
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.
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.