1 Reply Latest reply on Aug 1, 2018 5:04 AM by phoffmann

    Disk usage 100% - Vulscan or Inventory

    Denivanti Rookie



      Ivanti version:


      We encounter a problem raised by some of our users.

      When running the vulscan (vulscan.exe) or inventory scan (ldiscn32.exe), we see a 100% increase in disk utilization.

      When processes are in progress, the stations are slowed down to the point where users can no longer work.

      In the task manager, the processes saturate the disk are "ldiscn32.exe", "vulscan.exe" and also "wmiprvse.exe".

      The process "wmiprvse.exe" is initiated by the launch of "vulscan.exe" or "ldiscn32.exe".

      After checking through the event viewer, no other processes than the 2 mentioned above impact the WMI service.

      The incident is therefore related to the execution of the 2 Landesk processes. ("vulscan.exe" or "ldiscn32.exe").

      Tests performed:

      - Supression of the antivirus: The incident is repeated. => The antivirus is not in question.

      - Suspension of the service "Winmgmt" => The saturation of the disk is no longer present but the inventories of the posts are no longer.


      For information, a ticket has been opened to Ivanti support.

      While waiting for their return, I opened this conversation.

      If anyone has ever had this problem or have any ideas about a possible solution.


      Sorry for my English, I used Google trad.



        • 1. Re: Disk usage 100% - Vulscan or Inventory
          phoffmann SupportEmployee

          So a few points.


          • Inventory scanning (well - the software scanning) is going to be disk intensive.
          • Vulnerability scanning *CAN* be very disk intensive too.

            That's the nature of the respective beasts.


          Now - there are a bunch of other things to be aware of & things to do:

          • AV - I'd be careful about "turning the AV off" ... depending on the AV, that tends to be a bald-faced lie, actually .
          • Some AV's have "process level scanning" - that's a double-whammy to be aware of. Process-level scanning goes by various names (depending on AV used), for instance, Sophos call it "on-access" scanning.

            What is process level scanning?

            Instead of "old AV" thinking where it's a case of "oh, EXE xyz wants to run - I'll check it quickly ... yeah it's fine - go do your thing", its the following scenario:
            • Scan the exe that wants to run.
            • Scan *EVERYTHING* that this exe touches (which - for both inventory & vulnerability scans amounts to "not far off" a full disk scan). So you may want to put in exceptions for those in regards to process level scanning.
          • WMI doesn't get access by vulscan at all usually - that's usually only accessed by the inventory scanner. You can find information on the component (it's a part of data analytics that processes WMI rules) that was introduced with 2016.3 (see here -- About LDMS 2016.3 New Inventory Features  ) as "WMIRulesScan.exe".

            You can disable remove the WMIRulesScan.exe if you're not using, as per the following thread/articles:
          • You can MASSIVELY improve the vulnerability scanner by configuring the items you scan for (in short - "don't scan for vulnerabilities that have been replaced ... you're doubling up"). By default - if you "just download & run", we will scan for "every vulnerability known to man since the dawn of time" so to speak, which "can be very accurate" but not necessarily helpful since "those 10 vulnerabilities are in fact fixed by this 1 patch".

            So - make use of "replaced vulnerabilities" ... which can be done automagically for you here ... (click on the image for full size version)
          • Control the schedule. You can do yourself a lot of favours by controlling when (not to) run either the vulnerability scanner or the inventory scanner (i.e. "don't run it at logon time, when the device is super busy anyawy).

          • You can help or hinder yourself with how you configure your scanning tasks. We can be "kinder" or harsher to your devices ... a few settings such as this one:

            ... will make a difference. Equally will "show" vs "not show" UI.

            If the GUI is NOT displayed, then the scanner will be much gentler - a background process. If the GUI *IS* displayed, then the scanner will "run as harsh & quickly as possible" (because the assumption is that you're usually debugging something).


          ... that should give you a few things to look at / think about.


          Long story short - there's a LOT of factors invovled (and - even though your AV claims to have been disabled - that can be a surprisingly bald-faced lie, as I've found repeatedly) .

          1 of 1 people found this helpful