FileVersionInfo.GetVersionInfo() performance in threaded app

  • Thread starter Thread starter Magnus Koch
  • Start date Start date
M

Magnus Koch

Hi,
I'm working on a little deployment app to support .Net file deployments to
about 7 different locations on the network. It's somewhat intelligent in
that it only deploys changed files, and moves the old files to a backup
folder, so that most deployments can be done w/o booting all users off. The
network is pretty slow, so I built it so that each deployment (defined as
unique source/target folder combination) runs in a separate thread.

The issue I'm running into is that FileVersionInfo.GetVersionInfo seems to
either be running in a single thread below the surface, or have some other
issue with multithreading that I don't understand. Each call is at least
twice as long and, at regular intervals, the CPU utilization hits 100% and
stays there for 15-20 secs, with more than 50% Kernel Time, whatever that
might imply. The end result is that the app runs just as slow as in a single
thread, except it's even more annoying to watch.

The only obvious point of contention is that the threads may access the same
file in a source folder, but they are all local or on a fast connection, so
I can't see how it would hang it for that long.

Does anyone know what the issue is and how I can fix it? Would a separate
AppDomain help? Process?

Thanks,
Magnus
 
The decompiled code for FileVersionInfo.GetVersionInfo shows that routine
making win32 calls to GlobalAlloc, GlobalLock, and GetFileVersionInfo.
There's nothing obvious about why it would be hanging and I do not know of
any global mutex that would block when accessing those routines from
multiple threads. It does not appear to be serializing access through a
single thread. Perhaps someone else knows of a system wide lock that could
be causing this, but I suggest looking for something else in your code.
 
Back
Top