Jump to content

jlhatsfs

Members
  • Posts

    8
  • Joined

  • Last visited

About jlhatsfs

  • Rank
    Newbie
    Newbie

Profile Information

  • Location
    USA
  1. This is the default structure for Visual Studio projects. A project is developed in the User's Documents folder to keep them separate from other users on the computer. Debugging is done from the folder that was causing the problem. Once the application is finalized, the application .exe is built in a Release folder and the installer installs the release version on a target computer in a structure defined by the developer. I routinely install in a subfolder of the Program Files folder. User specific input and output data from the application is stored back in a subfolder of the user's Documents folder to keep them separate from the data of other user's and to assure that they are backed up by normal backups. BTW, the problem has stopped occurring. I suspect that the change of Detection Engine corrected the problem. @Marcos has not verified this, though.
  2. OK, here it is. Time;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here 9/4/2020 7:30:55 PM;Real-time file system protection;file;C:\Users\Jerry\Documents\Visual Studio 2017\Projects\MAnE\Exec\Mission Analysis Environment\bin\x86\debug\OrbitRel.dll;Suspicious Object;cleaned by deleting;SFS-HOME\Jerry;Event occurred on a new file created by the application: C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSBuild.exe (4547B24DB7A512B1F9A6E2ED0DCB7E7FEE0A9E24).;907C4C27F2F3110781DE9D2DF901C0826238FFA2;8/4/2020 11:27:20 PM
  3. @itman - I don't know what the Detection Log entry is that you refer to. Is it the report from the scan? A text file on my computer?
  4. That is correct. I just ran the application and there was no detection. The file now appears in the directory from which it was previously deleted. I then ran a scan on that file and it reported no detections as expected. The one thing different is that it said it used Detection Engine 21941. Previous scans used Detection Engine 21940. Was there a problem with the previous engine that caused the problem?
  5. Here is the Eset Detection log report. eis_threat_logs.zip
  6. I believe I know what is happening, but not why. I'm running my application in debug mode with Visual Studio 2017. That automatically compiles the application in the debug folder and collects the resources (including the DLL file) into that folder before running. ESET then checks the folder before execution and deletes the DLL file, even though a scan detects no problems. I hope you can help. Thanks. eis_logs.zip
  7. I am running ESET Internet Security v13.2.18.0. I have developed a C# application that makes calls to a Fortran DLL that I also developed. Each time I start the C# application, a ESET popup message appears as follows: Threat removed A threat (Suspicious) was found in a file that MSBuild.exe tried to access. The file has been deleted. When I click on file, it points to the DLL file in a directory in which the indicated file does not exist. I do have in in other directories and when I run a ESET scan on it, no problems are reported. Can you tell me what might be going on here? Thanks for your help. Jerry Horsewood
×
×
  • Create New...