So I've got an issue where our NSIS installers slow down heaps when installing over the top of an existing installation?
It seems to be directly related to Microsoft's Security Essentials and turning off runtime checking causes it to go away, but I've never encountered anything similar with any other installers - so is there a known issue here or should we be doing things differently to avoid this kind of thing?
To give you an idea how slow.. each .EXE takes 10-15 seconds to unpack but on a clean machine or with Security Essentials turned off it takes only a second or two - and this is on the a top of the line core i7 with 12GB of ram.
Only thing I can think of is to copy the exe to a temporary file and then move it over afterwards, but this seems a bit clunky.
You might consider switching to using Microsoft WIX instead, http://wix.sourceforge.net/ It works quite nicely, it's free, and it's supported by Microsoft. I'm fairly sure that Microsoft is not going to let it interact negatively with their own anti-virus.
The "killer moment" when I switched from nsis, was when one of the nsis uninstallers generated a false positive with microsoft defender. I then uploaded it to http://virustotal.com , and 5 out of 20 anti-virus scanners flagged it as a trojan. I'm not sure exactly what nsis uninstaller does to make it prone to false positives, but the idea of one of my not so many potential clients trying tentatively my software and then being told it is a virus fills me with horror!
-- Outdated answer. Microsoft Defender is kinda good now --
You're gonna hate me.
If you're competent, lose the antivirus.
Antivirus is only needed by those who are unable to keep their machines from getting infected without it.
I ran antivirus for years, and had it legitimately trip only once, on a six month old backup of my mail folder. What's weird is it sat for 6 months before the antivirus caught it. In the meantime, it tripped many times on false positives.
I don't run antivirus anymore and would be glad if I never ran it again.
Related
I'm trying to figure out what this generic description of malware means, googling it didn't turn up much
https://www.microsoft.com/en-us/wdsi/threats/malware-encyclopedia-description?name=Behavior%3aWin32%2fPersistence.DQ!ml&threatid=2147737492
I'm creating a desktop application/browser plugin. Today when I tried to installing and testing the latest version on windows 10 (earlier versions of the program didn't give cause this problem) windows defender reacted to the executable. It gave me the link above but that just gives some generic user information. It also allowed the program to continue to execute which I thought was odd but maybe more information on what this means might explain why. The program itself is not doing anything shady so I'm sure this is a false positive but I would like to know what Win32/Persistence.DQ!ml means, so I can try to avoid triggering false positives in the future.
For the last 3 days I have been trying to figure out how to install node.js. I tried every solution that I found on the internet, like disabling certain components during installation, installing both x86 and x64 etc, none of them worked.
My OS is Windows 10 x64. I tried different versions of node.js and they all return the same error shown in the screenshot below.
I tried installing through the command line and got the log. But I could not find anything useful from the log either. Please help.
The log can be found here: this path : https://drive.google.com/open?id=1OkkK36hlQeBX0xTNuOuilGaNr1u3S55e
MSI (s) (74:88) [20:49:45:955]: Executing op: ActionStart(Name=RegisterEventManifest,,)
MSI (s) (74:88) [20:49:45:961]: Executing op: CustomActionSchedule(Action=RegisterEventManifest,ActionType=3073,Source=BinaryData,Target=CAQuietExec,CustomActionData="wevtutil.exe" im "C:\Program Files\nodejs\node_etw_provider.man")
MSI (s) (74:A0) [20:49:45:969]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI33C1.tmp, Entrypoint: CAQuietExec
CAQuietExec: Error 0xc0000409: Command line returned an error.
This is the relevant part of the log and where the install keels over, noise removed. 0xc0000409 is very, very nasty. STATUS_STACK_BUFFER_OVERRUN is a stack corruption error, triggered by code that protects against viral attacks.
Searching for "nodejs install 0xc0000409" takes you to this bug report, notable from December 2015. This issue has been dogging users for a long time, but they are having trouble finding the root cause. The generic workaround is to disable this install step by disabling the installation of the ETW performance counters.
Which works, but is but a band-aid. I think macario1983's comment points at the real troublemaker. It got a lot of helpful votes in just two days. And points at the kind of viral rootkit that programmer's voluntarily install, the kind that can so easily cause a STATUS_STACK_BUFFER_OVERRUN error with no decent way to identify the code that causes it. Anti-malware has become a cure that is worse than the disease, Avast in particular is a truly awful product and does not belong on a programmer's machine.
So decent advice is to 1: disable the anti-malware product before installing Node. 2: get rid of completely if it is Avast. 3: disable the performance counter registration. 4: try the updated installer, patched 4 days ago.
I disabled the AVG antivirus(version 18.4.3056) but not windows firewall and then i was able to install nodejs.
Possible options to solve this:
1. Removing previous installations traces
If you have previous installations, make sure that they were uninstaled completely. If HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\_V2Providers\{1e2e15d7-3760-470e-8699-b9db5248edd5} record exist in your register, remove it.
2. Disabling Performance Counters
If you don't need Performance counters feature, try to install without it (or maybe even without Event Tracing).
3. Disabling security and giving the full permissions
Clean Temp Folder
Disable your antivirus/firewall for the period of installation.
C:/users/$user/AppData/Local/Temp- Right Click on Temp and go to Properties > select Security Tab > give the user permissions by checking Full Control on permission
Install Node.js
I had today the same problem with Windows 10 64 bit and Node.js 8.11.2: disabling completly Avast just for the time of the installation solved the issue.
I was trying to install Node.js through node-v8.11.2-x64.exe, but it was rolling back every time at the end. The error in the event log was about wevtutil.exe, version 10.0.17134.1
I had the same issue on a Windows 2012R2 server installing node-v8.11.2-x64, and disabled the McAfee anti-virus to no avail. When I went to clean out the TEMP folder as suggested in this thread, I noticed that several files and folders were locked and could not be deleted, so I rebooted the machine (with the anti-virus disabled). After the reboot, I noticed that the locked temp files had been deleted, and I was able to install node.js, including the Performance Counters and Event Tracking options.
I spent one day for that ....Best solutions is download zip example node-v12.16.2-win-x86.zip.
When I try to install pywin32-220 it will be stopped by Norton saying that it's threat name "SONAR.Heuristic.132" and a "High risk file". It removes the pywin32-220 installer... So how can I get pywin32?
Pywin32 download -
http://sourceforge.net/projects/pywin32/files/?source=navbar
SONAR.Heuristic.132 threat: (Norton link to details)
http://www.symantec.com/security_response/writeup.jsp?docid=2015-061517-5721-99&vid=4294925827&product=Norton%20Internet%20Security&version=22.5.5.15&plang=sym:EN&layouttype=OEM&buildname=OEM30&heartbeatID=0F625CD5-90AB-490B-A78F-5E1F18F05B2E&env=prod&vendorid=32430&plid=2&plgid=2&skup=21244261&skum=21349155&skuf=21228659&cipherid=0&endpointid=0F625CD5-90AB-490B-A78F-5E1F18F05B2E&partnerid=32430&lic_type=512&lic_attr=16928786&psn=XJGV3WXHYJKQ&puid=5578&osvers=6.2&oslocale=iso:GBR&oslang=iso:ENG&os=windows
(I use Windows 8, Python version 3.3.3)
I have installed Pywin32 for a different version of python before.
So what can I do to solve the issue? How can I install Pywin32?
Edit
Thank you for your informative answer... Not what I wanted but it helps.
Also I checked my computer's threat history today... It says that the Pywin32 installer's activities had installed a file in the appdata folder... Therefore it's probably a 3rd party, unwanted software. I don't know why a python plugin needs to install something in the appdata folder.
Also considering that 220 was roughly released 10 days ago ( upon writing ) it has over 8,000 downloads... It is no more than 1,000 (Indvidualy) for every single other one, and that the 220 installer is in question...
How can I install Pywin32?
If you trust the suppliers of PyWin32 more than you trust the suppliers of Norton, disable or uninstall your anti-virus and go ahead with installing PyWin32.
I can't make the decision for you which one you trust more, but in my opinion:
In general anti-virus today simply doesn't work. (It has been arguably been causing more problems than it solved for many years now, but these days it is proving nugatory protection for all the faff.) Signature-based scanning is dead in the face of dynamically-generated files from automated kits; heuristic-based scanning (which is what has flagged here) is rife with false positives for pretty much any executable.
PyWin32 is hosted on SourceForge, a site that has recently gained some notoriety for packaging installers with unwanted third-party software. I have not seen any evidence that this has happened to PyWin32 at this point, but who knows.
It is deeply unfortunate that you are put in the position of choosing to trust one or another party when they have both proven themselves distinctly untrustworthy in the past. But that's the filthy, stinking state of the Windows software marketplace today.
I am trying to fix a Windows 7 machine here that has been infected with all kinds of Malware. I have removed all of them as far as I can see but I am stumped by one last task.
One little bugger managed to remove the Windows Security Center service from the list of Windows services. So I cannot start it or set to automatically start. At the moment I cannot get the Windows firewall to turn on or any anti-virus software.
The security center shows this when I try:
Does anyone know how to add this back to the list of services so I may set it to start. I don't have a backup of the registry for this computer (it's not mine).
Many thanks
TT
You can never really be sure that you have removed all malware infections from a machine. There could be a myriad of registry keys/services that have been messed with.
My advise would be wipe it and reinstall Windows. This will undoubtedly fix your issues and you can then be sure you have removed the malware.
We are starting with Sharepoint development with a team of three and are currently setting up our development environments. We would like to avoid installing a Server 2008 for each developer, thus a single terminal server has been setup, using Remote Windows to start a VS2008 instance on each developer's machine. Now we would like to separate developers' testing environments (i.e. a different site colletion per developer), but have realized that the assemblies would need to be installed into GAC to show properly on the site. But since there is AFAIK only one GAC, developers wouldn't be able to test their stuff independently.
Is there any way we could create separate testing environments without installing a bunch of 2008 Servers?
So you're all going to remote in an fire up Visual Studio and be compiling stuff and restarting IIS, etc?
You're going to be stamping on each other's toes.
A wiser choice nowadays is to use Hyper-V (or some other virtualisation).
We use Windows Server 2008 on our laptops, and use Hyper-V to run our dev environments. We then have a dev environment (sandbox) each, and these have VS2008, SVN, Nunit, etc.
Our code is tested against each other thanks to CruiseControl on the only shared Hyper-V.
This has been great for us... we distribute the load, we can work on the move, we don't step on each others toes and if we need to do a demo we can switch Hyper-Vs and demo from the demo Hyper-V (branched from the dev one early on so that the environments are known).
Go virtual and don't look back.
PS: I've just seen your comment about one server... just put Hyper-V on that and run 3 instances. That's also what we do ;)
I don't know about installing the server on everything, but this sounds like an ideal task for Virtual Machines rather than physical ones- where I work we using VMWare a whole lot for this kind of work and it does very well.
It's also useful to be able to roll back to a snapshot when it comes to testing installation processes and so on.
No. In addition to the GAC there are all the SharePoint files in the 12 hive, such as features and site templates. It's not worth what you save on server costs.
(Of course if you don't use the GAC, but deploy to the bin folder, and you don't touch anything in the 12 hive, you can give each developer their own web application on the same server. But this approach puts a lot of restrictions on what they can do. It's still not worth it.)
Virtual machines will work, but they can be slow to develop on. For instance, you'll need to restart the application pool for every GAC deploy - which means a pause of maybe 15-60 seconds to reload the application, (depending on the hardware). This will become annoying.
Virtual machines work better for test and production, where you don't restart the application so often.
I recommend a physical server for each developer. This will minimize the code-deploy-test cycle time, and make sure they don't have to worry about stepping on each others toes.
You are on the wrong track with Terminal Services - its just not going to give you any separation.
A lot of people do recommend developing on W003/2008 server directly, and it does simplify some things like remote debugging.
I prefer the more traditional method of using VMWare to run virtual machines. These can be running on a local or remote host. Remote debugging is a little more complex to setup but still possible.
Finally - if possible then deploy to the bin dir rather than the GAC. This will make it much easier to deploy automatically after compilation.
The contributors are right that there are lots of stumbling blocks to multi-developer single server environments.
Number one developers will be trying to attach to the same Web Application process w2ps.exe so creating separate Web Applications on different ports is a must unless you are prepared to share time debugging. How to setup a development environment for sharepoint 2013
The second problem is when you try to collaborate and use shared components/features. Having a desire to work separately is debatable, I believe that the team developers should be collaborating and sharing so combing work is desirable to ensure seamless integration into a single final solution and that no work is duplicated. The multi-developer single server environment works perfectly until you try to collaborate 'One common mistake is to have one “development server” used by all team developers. Unless team members are working on totally unrelated components and never need to do common things such as restart IIS or attach a debugger to an IIS process, this type of environment generally doesn’t work well.' http://technet.microsoft.com/en-us/magazine/dn145990.aspx We made this mistake through lack of experience and knowledge, but once you make it it's possible to work round it.
My first attempt to share features was to copy developer 1's project into developer 2's solution and add a reference to it in developer’s 2's project and add all the features to developer 2's package. Deploying this works fine for developer 2, until as I discovered if developer 1 detaches their solution from the debugger it retracts the solution based on the duplicated solution id from the farm and therefore from each developer's web application. Therefore developer 2 has the rug pulled out from underneath them. Although this is a part solution and seemed to work for a while, it took me a while to work out what was happening and what combinations of dev 1 and 2 deployments make each other’s work and not work.
So I found a better solution. Under the project properties in Visual Studio under SharePoint tab there is a combo box called 'Auto-retract after debugging'. This by default retracts the solution when the developer stops the attached debugger and pulls the features out from underneath the other developers. Unticking this box prevents the retract and leaves each developers individual solutions deployed at farm level and on reattaching to the debugger just replaces the solution with minimal fuss.
In my experience recycling the IIS application pool is so fast other developers don't even notice, but with a larger team than 2 this might become more prevalent, so perhaps someone else could add their experiences. I also guess unless the other develops try to attach at exactly the same time that the recycle is happening it'll be fine, so is a really small chance of having a cross over time, and simply detaching and reattaching will fix this if it is ever experienced.