Monitor files accessed by a specific process

[sciawatt]

Hi all,

I'm trying to do the task in subject but I've no idea how to start... My goal is to check when a specific task (I've no control on it) opens up a specific file, in order to generate an alarm in an I/O board.

Basically I want to develop in LabVIEW what e.g."ProcessActivityView" does http://www.nirsoft.net/utils/process_activity_view.html .The software developer explains in the page listed above that the program works as follow: "After you select a process, ProcessActivityView inject a special helper dll (ProcessActivityViewHelper.dll) into the selected process. This dll intercepts the internal file I/O API of Windows, and sends the information back to ProcessActivityView utility".

Anybody knows how to do this or suggesting any other approach to implement my idea?

Many thanks in advance.

[enpe]

Hi,

You should ask to the software developer if he can provide you an API (dll wrapped) to use with Lbview or you can import directly the dll and you can try to handle it. To import a DLL in LAbview you have to use "Call Library Function Node" function. To help you i have attached an example that it's using Kernel32.dll to see Windows Task Manager. Good work! Have a nice day!

Enzo Perini,

Application Engineer

National Instruments

[sciawatt]

Dear Enzo,

Many thanks for helping.

Unfortunately I cannot ask to the developer to modify the original software since the it is no longer supported. "ProcessActivityView" works perfectly but from my limited understanding DLL injection is a sort of "hacking" non easily reproduced in Labview (ref. http://forums.ni.com/t5/LabVIEW/Injecting-a-DLL-into-an-EXE/m-p/1989545#M656302 ).

Is there any other alternative way to intercept files or folders opening from within Labview?

PS - I only have Labview 8.0, could please convert your example?

Many thanks,

Best regards

[smercurio_fc]

You don't need to look at that example to see how to use the Call Library Function node. An extensive example ships with LabVIEW (search for "DLL" in the Example Finder). That was the only purpose of the example - you can't actually use Task Manager to see when an application has opened a file.

As for accomplishing your objective, in general you'd need to use a driver filter, which is what ProcessActivityView does. As an alternative, you could simply try to open the file yourself for exclusive writing. If the file is already opened, you will get an error, which you can trap. Clunky, but quite simple. I think WMI can do this as well, but you'd have to search using Google/Bing/whatever to find out.

[sciawatt]

ok, clear.

I did some test trying to open the file, but the process I want to monitor doesn't lock it up (I can even delete the file while opened, just like txt files and notepad). No idea with WMI, it's very new to me, I'll give a look.

Thanks

[PhillipBrooks]

Take a look at this example. It uses .net and the filesystemwatcher class. http://forums.ni.com/t5/LabVIEW/My-First-Nugget-Directory-Changed-Event/m-p/1407552#M547202

[smercurio_fc]

---

@PhillipBrooks wrote:
Take a look at this example. It uses .net and the filesystemwatcher class. http://forums.ni.com/t5/LabVIEW/My-First-Nugget-Directory-Changed-Event/m-p/1407552#M547202

---

Unfortunately, the FileSystemWatcher class will not notify if an application merely opens a file.

If the file is being written to by the other app it would give you a nottification, but only if the other app flushes the stuff to disk.

[sciawatt]

I did also a test using "Handle" by Sysinternals. It returns the handle associated with the directory the process has opened, that could be enough to me. The problem is that the handle remains open also after the file has been read, so I cannot trigger the alarm when the file is re-read.

I've also identified the DLL used to open the file, I don't know if this can be useful.

[rolfk]

What you try to do is certainly possible as shown by tools like ProcessActivityView, and several SysInternalTools. But you should realize that these are tools that use some pretty advanced low level APIs that people like Mark Russinovich have spent many hours on to figure out how to make it work. And Mark Russinovich is not just a funky C hacker who happens to know how to call a C function, but very knowledgeable about these things, probably only surpassed by a few Microsoft programmers working on the Windows kernel.

Even with the full source code available of such a tool, creating your own tool to do what you want is a very non trivial task. That is entirely independant if you try to do that from LabVIEW or a C program, but not having the knowledge to do it all in C already disquallifies a person completely to do it for and even more so in LabVIEW.

In fact I would consider it easier to do all the heavy API lifting entirely in a DLL developed in C and just export two or three simple API functions to LabVIEW, than trying to inteface to the many Windows API calls this will require from LabVIEW directly. Just because LabVIEW can interface to Windows DLL APIs does not mean that this is the most sensible approach.

So this would mean that you have to create in fact two DLLs, one to hock the target process (which you could probably lift from the ProcessActivityView project verbatim) and another DLL doing some of the work, ProcessActivityView does and then is called from LabVIEW.

[PhillipBrooks]

---

@smercurio_fc wrote:

Unfortunately, the FileSystemWatcher class will not notify if an application merely opens a file.

If the file is being written to by the other app it would give you a nottification, but only if the other app flushes the stuff to disk.

---

I didn't realize that this was only a read of an existing file. From what I can tell, it should be possible to enable FileSystemWatcher to monitor LastAccess IF the file is local and the LastAccess flag in the registry is set properly (NtfsDisableLastAccessUpdate). The tradeoff is that every folder browse updates lastaccess, which might not be ideal.

I poked around and discovered that Microsoft provides libraries for something called a file system filter driver. It appears that the main use for these drivers is to allow apps such as virus protection and backup software to monitor/intercept file system I/O. 

This stackoverflow thread led me to a commercial product that uses these file system filter drivers called CallBackFilter. It probably doesn't apply to this particular problem but maybe this will be of use to someone who needs this sort of functionality in the future.

http://stackoverflow.com/questions/3621661/detect-file-read-in-c-sharp