100 replies to this topic

[erwan.l]

Very nice feedback and definitely a nice thread to keep in mind for devellopers on this forum !

 

Suggestion : if you really want to be handle network shares, to me the best API is WNetAddConnection2A.

 

Regarding VHD's (and ISO's !), i do use ms vhd native api's indeed, available on vista and up only.

To my knowledge this the only way unless you use additional drivers (imdisk, etc).

 

Regarding VHD informations, I parse the file header (i can share the code if you want).

[Zharif]

Thanks,

Edit:

WNetAddConnection2A works very well (in most circumstances). But an additional dll is needed (mpr.dll).

Till now I tried to avoid additional dependencies as much as possible.

But maybe I should reconsider my methods if I really try to increase usability of zDInfo.

As suggested elsewhere by Wonko, outsourcing the mount/unmount/label functions as a separate tool should be kept in mind.

 

Anyway, I'm still much interested on feedback about the output values for the current version of zDInfo.

 

Erwan, I compared the drive SerialNr of CloneDisk with zDInfo.

The code I use additionally gets the DeviceInstanceID/DeviceInstancePath of USB Devices

(as seen in Properties-->Details-->DropDownBox: DeviceInstancePath;

 example: SCSI\DISK&VEN_SAMSUNG&PROD_SSD_840_EVO_250G\4&15AD2E1C&0&000000).

I discovered that CloneDisk (v2.3.3) misses the last character/digit of the SerialNr for any kind of USB/Removable devices.

Any kind of a byte offset and/or length issue? But maybe this values go wrong for zDInfo instead for CloneDisk (or for both?).

Here're some examples:

 

USB3.0 harddisk connected:

DevInstID: USBSTOR\DISK&VEN_ST1000LM&PROD_024_HN-M101MBB&REV_2AR1\PROLIFICMP0000000D5&0
CloneDisk: RPLOFICIPM000000D

zDInfo:      RPLOFICIPM000000D05

 

Four slot "combo" SD card reader: One micro SD-Card inserted

DevInstID: USBSTOR\DISK&VEN_GENERIC-&PROD_SD/MMC&REV_1.00\20060413092100000&2

CloneDisk: 0260403190120000

zDInfo:       02604031901200000

 

Just for notification - you may want to have a look at this.?

 

BTW,

I found new issues regarding the flags used by DefineDosDevice. My latest post has been updated.

[erwan.l]

About mounting VHD/ISO, you can may be look at http://reboot.pro/fi...ile/477-vmount/for ideas.

 

About mpr.dll, i believe this is a "native" dll since windows 2000, i.e it should always be there on the system.

 

About serial number, i believe length is OK in clonedisk.

But now I wonder about the byte sequence

See below.

 

[Zharif]

About mounting VHD/ISO, you can may be look at http://reboot.pro/fi...ile/477-vmount/for ideas.

Oh, I see. Seems very nice. I did not enough research.

Again, I never intended to re-invent an already existing tool. Therefore, I will stop programming into this direction.

 

About mpr.dll:

I was not sure about it's native existance. Thanks for clarification.

 

 

 

about serial number, i believe length is OK in clonedisk. But now I wonder about the byte sequence

As you say.?

I'm aware about the wmic outputs or the ones seen in the DeviceInstanceID.

But codes or code snipsets I've seen so far in VB or C always tried to swap the byte order which in fact is additional code.

I also followed this method. However, in regard to wmic I ever wondered which SerialNr. string is correct.

I must confess that I don't know the answer.

[erwan.l]

Actually i do flip and code bytes (just like vendorid, productid, productrev) so i am pretty sure my serialnumber is right.

Could MS wmic be wrong ...?

[Zharif]

The StorageQueryProperty code is one of the two parts in zDInfo I borrowed from members of the VB Forums.

Initial tests seemed to work  - I've been too lazy to review this code in detail. But maybe I should.

At least it shouldn't be a problem to synchronise my values with yours.

But actually I still doubt in the output style (swapping/no-swapping the byte order) as well as in the correct use of this function itself.Regarding the wmi I encountered some curiosities in the past. Wonko pointed some of them out in the thread I linked to in my first post.

I wouldn't be impressed if wmic behaves wrong but I honestly don't know.

Maybe Wonko, cdob or some other experts are able to clarify this issue.

[cdob]

I wouldn't be impressed if wmic behaves wrong

wmic diskdrive get serialnumber
SerialNumber
TM7F296T0AWN

The label at the hdd
NWA0T692F7MT

WinDlg http://download.wdc....inDlg_v1_29.zip
Unit Serial Number: NWA0T692F7MT

Yes, wmic prints a reverse string.

[erwan.l]

Yes, wmic prints a reverse string.

 

 

@cdob : Thanks for clearing this out !

 

@Zharif : so your code is right but displays one digit too much if you ask me.

[Zharif]

Maybe I'm wrong here but I'm still in doubt.

Erwan, different SerialNr. only occur for USB/Removable drives.

Fixed drives are not affected.

 

cdob, I downloaded the DataLifeguard Tools and did a quick comparison.

 

Connected USB3.0 hard drive:

CloneDisk: RPLOFICIPM000000D0

zDInfo:       RPLOFICIPM000000D05

WinDlg:      S2TBJB0C281796   ???

 

Edit:

The other Serials (for my fixed drives) go fine and underline the assumption that wmic reverses the order of the SerialNr.

Edit:

Or maybe the SerialNr shown by wmic must be reversed while programatically retrieving it.

[Zharif]

Okay, I put this harddisk out of the enclosure and compared all these values with the printed SerialNr. on top.

Printed SerialNr equals the one WinDlg shows.

Means, CloneDisk and zDInfo values are wrong.?

[erwan.l]

Maybe I'm wrong here but I'm still in doubt.

Erwan, different SerialNr. only occur for USB/Removable drives.

Fixed drives are not affected.

 

cdob, I downloaded the DataLifeguard Tools and did a quick comparison.

 

Connected USB3.0 hard drive:

CloneDisk: RPLOFICIPM000000D0

zDInfo:       RPLOFICIPM000000D05

WinDlg:      S2TBJB0C281796   ???

 

Edit:

The other Serials (for my fixed drives) go fine and underline the assumption that wmic reverses the order of the SerialNr.

Edit:

Or maybe the SerialNr shown by wmic must be reversed while programatically retrieving it.

 

 

I am getting different results as well

 

i am flipping bytes.

i believe wmic does not.

 

apart from flipping, wmic and clonedisk are giving same results.

 

I believe windlg is not flipping bytes just like wmic.

but it does find a unique result for USB.

 

 

 

[erwan.l]

ignore - double post ...

[cdob]

Okay, I put this harddisk out of the box and compared all these values with the printed SerialNr. on top.
Printed SerialNr equals the one WinDlg shows.

I trust WinDlg and Smartmontools
https://www.smartmon...g/wiki/Download
http://sourceforge.n...ce=typ_redirect

smartctl.exe -a /dev/sda

It's open source, if any questions left asks Christian
https://www.smartmon...s.org/wiki/Team
https://cygwin.com/m...6/msg00043.html

[erwan.l]

Latest clonedisk version (2.3.4) does not flip code anymore for the disk serial number.

 

Now, wmic / windlg / clonedisk all get the same datas for fixed hard drives but NOT for USB disks ...

 

Indeed, it seems the way to retrieve a serial number for a usb disk is different.

You can actually find this serial number in the registry (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\UsbStor\enum) or by using SetupDiGetDeviceInterfaceDetail windows API.

 

[Zharif]

For me, reversing is not the real problem.

It's simple for my command line tool to show the same results as CloneDisk or WinDlg (for fixed drives).

 

I'm with cdob here. I also want to trust the SerialNr. printed on top of the case of a hard drive regardless if its connected as a fixed drive or as a removable one. If a constant exist - this should be the one. I did a short test and connected my usb drive via adapter at the sata port of my motherboard.

This results in a SerialNr equal to WinDlg (by forgetting reverse of the SerialNr. which must be changed for my tool).

 

Obviously, codes we use are not able to retrieve the real SerialNr. of a drive if it is detected as a removable/usb drive.

Reworking is needed here.

 

Edit:

cdob, it might be worth a try to ask Christian how they programatically retrieved the disk info (incl. the SerialNr.).

But I'm really afraid how to "translate" positive feedback into the VB language.

[erwan.l]

For me, reversing is not the real problem.

It's simple for my command line tool to show the same results as CloneDisk or WinDlg (for fixed drives).

 

I'm with cdob here. I also want to trust the SerialNr. printed on top of the case of a hard drive regardless if its connected as a fixed drive or as a removable one. If a constant exist - this should be the one. I did a short test and connected my usb drive via adapter at the sata port of my motherboard.

This results in SerialNr equal to WinDlg (by forgetting reverse of the SerialNr. which must be changed for my tool).

 

Obviously, codes we use are not able to retrieve the real SerialNr. of a drive if it is detected as a removable/usb drive.

Reworking is needed here.

 

Edit:

cdob, it might be worth a try to ask Christian how they programatically retrieved the disk info (incl. the SerialNr.).

But I'm really afraid how to "translate" positive feedback into the VB language.

 

 

I did not yet look at smartmon source code but I am pretty sure using windows setupapi api's is the only way.

 

Zharif : can you summarize what you did with your usb drive?

Posting serial number(s) you get before and after with wmic and windlg would help.

 

To me the serial number is within the disk electronic : it looks like plugging it to UBS changes the way windows reads it? the usb interface electronic would come in the way?

[Zharif]

Yes, but my borrowed code already uses setupapi API's to get the serial of USB drives.

This is the link to the original code Dilettante from the VB Forums referred to (written in VB.Net):

http://emmet-gray.com/Samples.html

 

Please give me some time to summarise the actions. It's late now.

[Zharif]

As Erwan, I updated my tool to v1.3.1
It may be downloaded via link of the first post.

Erwan, here're test results:
I do have three hdd connected at the sata ports of my motherboard.
Furthermore I have a front panel that redirects some of the motherboard ports.
It contains a four combo Card Reader device, four USB2.0, two USB3.0 and one eSata port.

Okay, I did some tests for three mobile hdd's that can be connected either via USB or eSata.
To make things short, results of one hdd are "presented" here.

The s/n printed on top of the enclosure of my test mobile hdd is: S2TBJB0C281796.

1. Connect it via USB3.0 port at the front panel.
It is detected as hd7, DrvBusType is USB (see zDInfo)
Results:
smartctl -a /dev/pd7:       S2TBJB0C281796
WinDlg:                            S2TBJB0C281796
wmic:                                PROLIFICMP0000000D5
clonedisk (2.3.3):              RPLOFICIPM000000D0
zdinfo /DF:1|find "[hd7": RPLOFICIPM000000D05

2. Now I disconnect the drive, and reconnect it via eSata port of the front panel (inside this session).
Still, it is detected as hd7, DrvBusType is USB (see zDInfo).
Sometimes (I don't know why) devices are availale as SATA devices without reboot.
Results:
smartctl -a /dev/pd7:       S2TBJB0C281796
WinDlg:                            S2TBJB0C281796 (sometimes "Not Available" (reboot required))
wmic:                                PROLIFICMP0000000D5
clonedisk (2.3.3):              RPLOFICIPM000000D0
zdinfo /DF:1|find "[hd7": RPLOFICIPM000000D05

3. Reboot
As expected hd7 becomes hd3 for me.
It is detected as hd3, DrvBusType is SATA (see zDInfo)
Results:
smartctl -a /dev/pd3:      S2TBJB0C281796
WinDlg:                            S2TBJB0C281796
wmic:                                S2TBJB0C281796
clonedisk:                         2SBTBJC0827169
zdinfo /DF:1|find "[hd3": S2TBJB0C281796

Note:
Instead of step 2 you could also shutdown the computer and then connect mobile
hdds directly at the sata port of the motherboard (I did - an adapter is needed).

Results show that s/n of drives connected via ATA/SATA are displayed correctly.
They're not displayed correctly by clonedisk or zdinfo if detected as USB devices.
So, don't trust clonedisk and zdinfo in these cases. You may trust smartctl or WinDlg.
Again, rework is required.
 

[erwan.l]

Ok so it is clear that we need rework our code when it comes to fetch informations (maybe more than just the S/N) from USB devices.

 

When connected to USB, clonedisk and zdinfo get information from the USB motherboard (PROLIFIC is a well knonw USB chipset) instead of the disk motherboard.

 

Latest version of clonedisk (2.3.4) will display the S/N correctly, you may want to download this one.

[Zharif]

Latest version of clonedisk (2.3.4) will display the S/N correctly, you may want to download this one.

 

I would, but I can't.

 

http://reboot.pro/fi...d/24-clonedisk/

The first mirror let me download v.233, the second one reports a broken archive while trying to open the downloaded file.

[erwan.l]

I would, but I can't.

 

http://reboot.pro/fi...d/24-clonedisk/

The first mirror let me download v.233, the second one reports a broken archive while trying to open the downloaded file.

 

damn, windows built in zip feature sucks

 

i fixed the zip file and uploaded to both mirrors.

 

thanks for reporting this.

[erwan.l]

By the way, apart from setup api's for USB devices, here below the 4 different ways (thru deviceiocontrol) I know to retrieve storage informations.

I myself use the last one in CloneDisk.

 

-IOCTL_SCSI_MINIPORT

-SMART_RCV_DRIVE_DATA

-DFP_GET_VERSION

-IOCTL_STORAGE_QUERY_PROPERTY

[Zharif]

The second one I know and I tried this once ago.

Drawbacks as far as I remember:

- A maximum of four hd's connected at the ata/sata ports of the motherboard were supported? (Edit: not true)

- must run elevated?

 

But I still have this code stored somewhere. May have a closer re-look.

 

I use the same IOCTL as you (the forth one).

But my code additionally consists of a class module which calls the setupapi API's.

Will check the other ones - thanks.

 

BTW, the first mirror still consists of v2.3.3. The second mirror works now.

[Zharif]

Erwan,

I checked the code mentioned above.

It uses the following IOCTL control codes:

DFP_GET_VERSION
DFP_SEND_DRIVE_COMMAND
DFP_RECEIVE_DRIVE_DATA

As far as I see it's only working for devices connected via ata/sata ports.

CreateFile needs the usual access rights: GENERIC_READ Or GENERIC_WRITE (means you need admin rights)

DFP_GET_VERSION fails for devices connected via USB ports which is prerequisite for the other two control codes.

 

I do have two example projects (in VB)

Is it of worth for you to check them?

Please let me know and I will send you a mail.

 

I think I will have a look at the source code of the smartmonitoring tools (if available).

[erwan.l]

 

 

I do have two example projects (in VB)

Is it of worth for you to check them?

Please let me know and I will send you a mail.

 

 

I started my IT career as developper using VB6 so sure (hands of keyboard nowadays...) , I'd be happy to have a look !

 

Regards,

Erwan