Process Monitor : Help on IRP_MJ_READ Process Name!

The client system is a 32GB Hyper-V Guest that currently uses about 12GB of that memory for applications with the rest free. It is terminal services with about 30 office type clients running on it.

 

It is running Win2012R2 Standard fully patched etc. and seems to run well with about a 50% general performance improvement over the old server.

 

We have ~500 clients using this section of our software in the general market place, with the 3rd party 32 bit DLL that makes the file access being used the last 15 years or more by ourselves and also by about 80% of whole UK/Irish insurance market without issue.

 

The DLL relies on the files it is using to be cached by the Windows File Caching system for good performance - basically 1 second to run vs over 10 seconds without Windows caching.

 

The client was successfully running the software on Win2003 for several years and all of our other clients successfully run the software but of the 500 or so clients only half a dozen are using Win2012 with at present just this client seeing issues.

 

The problem is sporadic but when it starts it seems to hang around for a while :(. There seems no pattern to it that is obvious, with the standby list size floating around the 5GB to 8GB mark and lots of truly free memory stated by Windows.

 

Overview of the problem is as follows:-

 

The client's system has more than enough memory to cache all local drive accesses in the page standby list (Windows caches all local attached storage as it can handle cache coherency easily with it, network storage uses SMB2/SMB3 and opp locking and there are several issues with that but local direct storage apparently is not meant to have them).

 

When the slowing of the application happens ProcMon shows that Windows has disallowed FASTIO and defaulted to IRP instead AND the PID making the access is now SYSTEM! This is a WoW64 run 32 bit application so not sure if that changes the access names for IRP work?

 

When the application is working as expected the PID/ProcessName is the expected "XRTEClient.exe" and FASTIO is allowed and used.

 

While checking in RAMMAP for the cached files they appear to be there but do not appear to be being used as expected.

 

if the system is slow I see IRP use for the file access and Process Name as System in ProcMon...

 

 

While it is working as expected I see the expected proper name and FASTIO...

 

 

ProcMon also shows that the other direct mapped drive (E:) always caches files as expected and nearly everything is FASTIO as expected so the problem seems related to the C: drive only. C and E seem to be set up the same with no underlying differences.

 

When the problem occurs VERY LITTLE FASTIO happens for any other application including Outlook/Excel and Word so it appears that our own software is not the issue as such as FASTIO in general is getting ignored but not for everything.

 

I have contacted Microsoft and spent over an hour of my life simply to be told post it on a forum so ended up here.

 

I Googled this and some were having issues with the C: drive with the first partition being very slow in Win8 but this doesn't seem to relate to this client and Microsoft are not saying there is an issue.

 

Has anyone any related problems such as this or indeed can tell me why the shift from XRTEClient to System as the process accessing the file?

 

Any help would really be appreciated :).

 

Best regards,

Brian