OCS inventory crashing when enumerating disk drives.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OCS Inventory: Windows Agent |
Fix Committed
|
Medium
|
Didier Liroulet |
Bug Description
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.
Faulting module path: C:\Windows\
Report Id: 5f196ed3-
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 GetStoragePerip
<Manufacturer: (Standard disk drives)><Caption: HP MSA2312sa Multi-Path Disk Device>
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 CStoragePeriphe
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
Related branches
Changed in ocsinventory-windows-agent: | |
assignee: | nobody → Didier Liroulet (dliroulet) |
Changed in ocsinventory-windows-agent: | |
importance: | Undecided → Medium |
Changed in ocsinventory-windows-agent: | |
status: | New → Fix Committed |
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-7ff540f984 64/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