1 reply to this topic

[Victor Milovanov]

Hi,

 

I'm developing custom disk driver using ImDisk.NET wrapper, which works through DevIO. I'm experiencing problems with driver:

- delayed write failure messages from NTFS driver

- sometimes it stops responding

 

So I want to find causes for these issues. However:

1. I miss logging. Can I setup ImDisk to log all requests from the system and results (success/fail) somewhere? The same question for ImDisk.NET. Fortunately, I can reproduce the issues even on relatively small virtual drives, so storing full access logs will be fine for me.
2. I've setup remote debugging in virtual machine for my C# code. However, at the moment when driver stops responding, Visual Studio Remote Debugger also stops responding for some reason, despite the fact, that it has nothing to do with virtual disks my driver creates for testing purposes.
3. Last resort option: setup kernel debugging for ImDisk. Can someone share manual on his successful setup for it?

[Olof Lagerkvist]

The best option would in my opinion be kernel debugging. It is always difficult for a driver to log its own time and resource critical code sections to the debugged machine itself. It is not even possible to write to files at all from all code where logging would be of interest. It would require some kind of temporary buffer/lazy-flush mechanism to get that working, of course with the obvious risk of not getting the most interesting log message before a problem happens...

 

Therefore, kernel debugging is better in all possible respects, in my opinion.

 

There is a debug level definition in sys\imdisk.c:

#define DEBUG_LEVEL 0

Change that to

#define DEBUG_LEVEL 2
 

This will cause imdisk.sys to print out lots of debug messages, both for what it receives from filesystem drivers and for what it sends to proxy service.