2 Replies Latest reply on Feb 6, 2015 4:57 PM by dblansky

    Inventory scan failing - going to errorscan folder


      9.6 sp1

      agent was just reinstalled on the client

      ran coredbutil on datamart & damartpm.xml already with INV service stopped.  restarted the service afterwards

      event viewer shows this error:

      not quite sure how to fix it.

      Image 2.jpg

        • 1. Re: Inventory scan failing - going to errorscan folder

          Check the version of ldiscn32.exe on your client machine.  Is it  I'm using the latest component patch so my version is  It appears that there is a mismatch between the scanner (ldiscn32.exe) and the database.  Look inside the scan file in ErrorScan and search for the line


          Security - Antivirus Software - Antivirus


          You should see something like


          Security - Antivirus Software - Antivirus - (Number: 0) - Product Name =<some product name>


          My guess is that you're either missing the (Number) portion, or you're missing the actual number (Number:).  Number is the unique identifier for AntiVirus.  Based on the error above, the inventory service isn't finding a value for "number" in your scan file, so it's leaving it blank, resulting in a NULL.  That's not valid, so you get the exception.


          1. Verify your scanner on your client is up-to-date.  If it isn't, redeploy your client.  Make sure that the version of ManagementSuite\LDLogon\ldiscn32.exe on your core matches the version on your client.

          2. Find the lines in your scan file and paste them in a reply, along with the version of the ldiscn32.exe from your client.  The Date Created and Date Modified would be helpful as well as the File Size.

          1 of 1 people found this helpful
          • 2. Re: Inventory scan failing - going to errorscan folder

            I removed the pc a 2nd time from LANDesk & let it cook for a day rather than kick off a scan manually- the scans finally started populating the inventory correctly.  Not sure what the problem was exactly, maybe something corrupt for that entry in the db that took longer than expected to clean up.


            Scanner was indeed the correct version