spyware - msvcr71 and msvcp71

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hello,

I found the following msvcp71.dll and msvcr71.dll in a folder called
Spydawn. I thought Spydawn was spyware so I ran windows defender and avast
anti-virus; neither of them picked the spydawn folder up as spyware. Both
programs said my computer was completely healthy.

Anyone know how to get rid of this program?
 
It's adware. Download and run LavaSoft's AdAware personal and Spybot
Search and Destroy. They are both free.
 
For the record, msvcr71.dll and msvcp71.dll are both redistributables from
Microsoft's Visual Studio. msvcr71.dll is the C run-time library and
msvcp71.dll is the C++ run-time library. That's not to say that some malware
couldn't use those names, nor that malware couldn't redistribute them. It
only means that it is possible that those particular files are not actually
malicious.

As for spydawn, I'm sure jane is right.
 
If they are not where they are supposed to be in the operating system, the
likelihood is very high that they ARE malicious.

--


Regards,

Richard Urban
Microsoft MVP Windows Shell/User
(For email, remove the obvious from my address)

Quote from George Ankner:
If you knew as much as you think you know,
You would realize that you don't know what you thought you knew!
 
Those files have no defined place in the Operating System. They are used for
dynamic linking of the Visual C/C++ run-times and an application should
redistribute the version they need and install it wherever it installs
itself. You are thinking about msvcrt.dll/msvcprt.dll, which live in
%systemroot%\system32. Those latter ones are to be used primarily for the
operating system, although it is quite common for applications to use them as
well since it reduces the size of your distro.

Here is more info:
http://msdn2.microsoft.com/fr-fr/library/abx4dbyh(VS.71).aspx
 
Both of those files are in my system32 folder, courtesy of Visual
Studio.net. They are older files but at least they are in an accepted place.




--


Regards,

Richard Urban
Microsoft MVP Windows Shell/User
(For email, remove the obvious from my address)

Quote from George Ankner:
If you knew as much as you think you know,
You would realize that you don't know what you thought you knew!
 
Yep, but applications are not supposed to load them from there. They will,
because of how the DLL search order works, but that's not where they are
supposed to come from. If you write an application without the /MD switch in
the linker and take it, without msvcr71.dll, to a system that has never had
VS installed the app will fail. Those files are not shipped with the OS, and
hence, have no defined location they should live.
 
Jesper said:
Yep, but applications are not supposed to load them from there. They will,
because of how the DLL search order works, but that's not where they are
supposed to come from. If you write an application without the /MD switch
in
the linker and take it, without msvcr71.dll, to a system that has never
had
VS installed the app will fail. Those files are not shipped with the OS,
and
hence, have no defined location they should live.
Click to expand...

While your main point is correct, your comment about the search order is not
( beginning with xp sp2):
http://msdn2.microsoft.com/en-us/library/ms682586.aspx

If SafeDllSearchMode is enabled, the search order is as follows:

1.. The directory from which the application loaded.
2.. The system directory. Use the GetSystemDirectory function to get the
path of this directory.
3.. The 16-bit system directory. There is no function that obtains the
path of this directory, but it is searched.
4.. The Windows directory. Use the GetWindowsDirectory function to get the
path of this directory.
5.. The current directory.
6.. The directories that are listed in the PATH environment variable. Note
that this does not include the per-application path specified by the App
Paths registry key.

So this application will correctly load the dlls shipped with the
application.
 
Back
Top