OCS inventory crashing when enumerating disk drives.

[Keith Jones]

Hi,

 My apologies if this is not very clear. I'm not very good with C++ so I'm reading the actual code with a bit of "guesswork" whilst trying to get a grasp on the problem :-)

I'm getting two Error events on a couple of our HP servers.

First;

Event ID: 1000
Faulting application name: OCSInventory.exe, version: 2.1.1.1, time stamp: 0x537a7dfe
Faulting module name: MSVCR90.dll, version: 9.0.30729.6871, time stamp: 0x4fee6073
Exception code: 0xc0000417
Fault offset: 0x0003523b
Faulting process id: 0x2de8
Faulting application start time: 0x01cfb10b11ae58e7
Faulting application path: C:\Program Files (x86)\OCS Inventory (2.1.1.1)\OCSInventory.exe
Faulting module path: C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6871_none_50944e7cbcb706e5\MSVCR90.dll
Report Id: 5f196ed3-1cfe-11e4-9426-0025b31f4488
Faulting package full name:
Faulting package-relative application ID:

and shortly afterwards;

Event Id: 20
Service encounter error <OCS Inventory NG Agent encounter an error (exit code is 255 => Unknown code !)>.

When I look in the Sysinfo log I can see that the agent has stopped when enumerating the first Win32_DiskDrive

eg.

WMI GetStoragePeripherals: Trying to find Win32_DiskDrive WMI objects...
  <Manufacturer: (Standard disk drives)><Caption: HP MSA2312sa Multi-Path Disk Device><Description: Disk drive><Name: //./PHYSICALDRIVE18><MediaType: Fixed hard disk media><Size: 15257><S/N:

 The dead stop suggests it's having problems decoding the Serial Number.

 If I look at that drive using WMIC, then it looks like a proper 32 character ASCII encoded hex string (no hidden control characters). If I look at the other drives I can see one with a pure text serial (ie not hex-coded). Perhaps that is the real culprit?

 I know that WMIC had reported issues with devices that the manufacturer had used raw text in that field. I believe that MS don't actually specify it has to be anything but a string so I guess it's not unexpected that there isn't a standard :-)

Reading the coding in CStoragePeripheral::SetSN, I'm think that there might be a need for more sanity checking for the serial number field before trying to decode it as hex.

 Perhaps;

   a) Discard entries where there are non-printable characters and use a blank string (see Bug #1249006???)
   b) Check the string through for characters safe for hex decoding;
       I) if all characters are valid hex then parse the string as hex and use that
       2) if non-hex characters are found assume the serial number is raw text and return it un-processed.
  c) Truncate the string to fit the database field if necessary.

 I think this issue is entirely related to Bug #1249006 but showing up in a completely different context.

 Thoughts?

 Happy to try stuff out.

 best Regards, Keith

PS: using Agent : 2.1.1

[Keith Jones (k-e-jones)]

Hi again (again),

 I just posted an article I'd found to Didier's request (Bug #1249006) with the realization that it actually was something common to both our bug reports.

 If you're not of a sensitive nature there's a full on geek argument on technet arguing the pro's and cons of WMI behaviour with disk/volume serial numbers (http://social.technet.microsoft.com/Forums/scriptcenter/en-US/0333dd28-3207-4df8-85c3-7ff540f98464/wmi-disk-serial-number?forum=ITCG).

 In essence, it appears that vendors definitely don't work to a common standard. Although it appears that the serial number for a disk (or volume) is encoded as a hex string, it just as likely that it's not. Didier's issue seems to arise from the disk serial number looking like a perfectly convertible hex string but ending up with a binary mess. The same is probably happening for me too.

 Can I un-suggest the solution idea's above and re-suggest the following please?

 a) Discard entries where there are non-printable characters and return a string to indicate that the encoding was "<unrecognizable>" to highlight the issue.
     - because, if there are endian and ascii vs unicode issues it's too hard to guess at the vendor's intentions.
 b) Otherwise return the serial number as is
    - because, it's equally impossible to tell if a disk serial number is genuinely hex encoded or just abstract;y named in a hex-like way

 I appreciate that this will mean some thinking about the field lengths in the server but it feels like it would a more robust approach.

 The technet thread suggests that disk serial numbers being hex encoded is a bit of an urban myth...

 Regards,

Keith

[Didier Liroulet (dliroulet)]

Hi Keith,

I've applied the follwoing algorythm:

If Disk S/N is hex encoded, try to decode it and ensure it is printable
otherwise if not is printable, hex encode it

I've build attached version 2.1.1.2 (pre 2.2) of OCS agent.

Could try it and esure it is not crashing ?

Regards

[Keith Jones (k-e-jones)]

Hi Didier,

 I'm deeply sorry for being so slow to respond . I did something crazy and actually took some holiday for a change :-)

 That did the job! The servers concerned now all run the agent perfectly and report all disks in the logs. They're also uploading data to the server nicely so, although it doesn't look like anyone's responded on the other bug, I think you've fixed the problem there too. I'll stick a note on that bug to "bump" it :-)

  Thank you very much for taking it on-board and delivering the fix. It is appreciated.

 Muchas gracias (Yes, I went to Spain for a holiday and did indeed learn the correct gender of gracias :-))

Regards,

Keith