Excessive Compile time when connected via VPN

[DavidWhite]

I previously posted Q's relating to this issue believing that I had an issue with VS2005. I now wonder whether the issue is due to IVF or possibly (remote) a virus on my machine.

The scenario is that we are compelled to have My Documents on a network drive, which is setup as an Offline folder so it can be used when not on the LAN.

I have set all of MSVS's settings that point to My Documents to point to C:\Dev.

My build times are (for full solution Rebuild):
When offline: 107 sec
Online (direct LAN connection): 141 sec
VPN connection: 1500 sec

Using ProcMon this afternoon, I discovered that repeatedly ifort.exe and fortcom.exe attempt to open and then create files called HookDLL.DLL and diagsfUI.dll in subfolders of My Documents (on the network drive). At least some of these folders are install folders used for applications created by me using IVF, but which are unrelated to the current build.

Some references on the web for HookDLL.DLL suggest it could have trojan activity.

What are these programs attempting to do these writes? why are they accessing these folders? Do I have a virus? Or is there a bug in IVF?

Thanks,


David

[Steven_L_Intel1]

diagsFui.dll is a dll containing diagnostic messages. It is part of the compiler install - I suspect what you are seeing is an attempt to open it. I am not sure why it is looking in MyDocuments first. I don't recognize HookDLL.dll, though that I think is a general mechanism used to load DLLs (such as antivirus, etc.) when any program runs.

I'll ask our diagnostic message experts about the DLL behavior.

[DavidWhite]

Quoting - Steve Lionel (Intel)

diagsFui.dll is a dll containing diagnostic messages. It is part of the compiler install - I suspect what you are seeing is an attempt to open it. I am not sure why it is looking in MyDocuments first. I don't recognize HookDLL.dll, though that I think is a general mechanism used to load DLLs (such as antivirus, etc.) when any program runs.

I'll ask our diagnostic message experts about the DLL behavior.

Steve,

Did you ever get a response to this? I did report it (issue 547088).

I can get around this by setting up a cmd to remove my network drive (where my documents is) from the path before I open VS, but then I cannot debug e.g. DLL projects called from Excel.

I have attached part of the logfile from Procmon showing the accesses during a build.

Thanks,

David

[Steven_L_Intel1]

The compiler is not doing this deliberately. A LoadLibrary is being done, but it should be looking first in the compiler install folder and not in your "default" folder. I'll take another look at this.

[jimdempseyatthecove]

Dave,

Check your environment variables for "...My Documents..."
Reorder (move further to right on line) or remove when (if)not necessary.

Something (maybe some demo version of a program) may have included "...My Documents..." in one of the environment variables. Hopefully this is not PATH.

Jim Dempsey

[DavidWhite]

Quoting - jimdempseyatthecove

Dave,

Check your environment variables for "...My Documents..."
Reorder (move further to right on line) or remove when (if)not necessary.

Something (maybe some demo version of a program) may have included "...My Documents..." in one of the environment variables. Hopefully this is not PATH.

Jim Dempsey

Only place My Documents occurs is in my personal PATH, which gets appended to the System PATH, so all of the MSVS, Fortran, etc, folders should be searched long before getting to My Documents.

D

[jimdempseyatthecove]

David,

Is your current drive and directory on the VPN?
(current drive and directory searched first, then PATH, then ...)

This may require you explicitly specify solution and project located over VPN (if I understand your file placement) instead of implicitly over the VPN by way of explicitly setting current drive and directory over VPN.

Jim Dempsey

[DavidWhite]

Quoting - jimdempseyatthecove

David,

Is your current drive and directory on the VPN?
(current drive and directory searched first, then PATH, then ...)

This may require you explicitly specify solution and project located over VPN (if I understand your file placement) instead of implicitly over the VPN by way of explicitly setting current drive and directory over VPN.

Jim Dempsey

Jim,

All of my project files, solutions, source files, intermediates, libraries, and executables generated by MSVS are located on C:Dev and child folders.

By corporate policy, the current user's My Documents is located on the network drive mapped as P: (and are synchronised to the local drive).

I have also pointed all of the MSVS folders which normally save settings to My Documents to c:

As shown in the ProcMon output, both fortcom and ifort are attempting to search folders under My Documents.

Normally, when I am connected to the LAN directly, there is no appreciable difference in compile time compared to when I am disconnected. However, the slower access through the VPN means that these very many accesses to My Documents searching for these two DLL's extends the compile time by more than 10x.

As stated earlier, I now use a cmd file to save my current path, set it to include the MSVS and IVF folders only, call devenv, and then reset the path after exiting MSVS. This solves the problem while on the VPN, but makes running Excel for debugging impossible without adding more system folders to this cmd file.

Thanks,

David

[DavidWhite]

Steve,

This issue of search files on the PATH by the compiler is stil present in v12 with MSVS 2010.

Having recently upgraded to both, the cmd file I had created previously got lost.

Consequently I again suffered excessive compile times while connected on VPN, due to the PATH, including the network copy of "My Documents" being searched repeatedly. Compile times go out from seconds to 10's of minutes.

I have recreated the work around, so that I replace the PATH with just the folders required for IVF and the windows folder, and restore them after exiting devenv.

Wished there was an easier way.

David