none
Setup API: SetupDiGetClassDevs fails when listing drives with "SCSI" enumerator RRS feed

  • Question

  • Hello,

    I've asked this problem on StackOverflow but haven't yet received any decent feedback.  So, I'm going to try here.  If you wish to read my article there, you find it at this link.  Basically, I'm using the function SetupDiGetClassDevs() as described here to list drives that are present in the system.  There is a code sample provided below which illustrates the problem.  All is well when I call SetupDiGetClassDevs() using the "IDE" enumerator, but when I call with "SCSI", the function fails and GetLastError() returns 13 (ERROR_INVALID_DATA).  What???

    I know I'm calling this function correctly.  On my dev box, I have no problems with this whether a SCSI enumerated disk is installed or not.  Basically, the function should return an empty list, or rather a handle to and empty list, if there are no disks installed with the supplied enumerator.  As my original post to Stackoverflow mentions, I've seen this only on this one laptop that I was testing with.  The laptop had no SCSI drives installed.  On every other system I've tested this, and the many hundreds of systems my customers use this code on, I've not seen this.  I'm hoping that someone here will be able to shed some light on this issue.

    Thanks, Andy

    (Code which does actually show the problem when run on this laptop I spoke of)

    #include <iostream>
    #include <Windows.h>
    #include <SetupAPI.h>
    #include <cfgmgr32.h>
    #include <devguid.h>
    
    int main() {
        std::cout << "Looking for only SCSI disks" << std::endl;
        HDEVINFO hDevs(SetupDiGetClassDevs(&GUID_DEVCLASS_DISKDRIVE, "SCSI", NULL, DIGCF_PRESENT));
        if(INVALID_HANDLE_VALUE == hDevs) {
            DWORD error(GetLastError());
            std::cout << "Handle returned is invalid. Error code: " << error << std::endl;
            return 1;
        }
    
        SP_DEVINFO_DATA sp = {sizeof(SP_DEVINFO_DATA)};
        char buff[256];
        memset(buff, 0, 256);
        DWORD index(0);
    
        std::cout << "The handle is valid, listing drives now" << std::endl;
        while(SetupDiEnumDeviceInfo(hDevs, index++, &sp)) {
            CM_Get_Device_ID(sp.DevInst, buff, 256, 0);
            std::cout << buff << std::endl;
            memset(buff, 0, 256);
        }
    
        SetupDiDestroyDeviceInfoList(hDevs);
        return 0;
    }
    
    

    • Moved by Jesse Jiang Friday, January 25, 2013 8:46 AM
    Thursday, January 24, 2013 4:10 PM

Answers

  • For windows 7, if the system has never seen a device under the SCSI enumerator before, the error you are seeing is expected.  If the system has ever seen a device under the SCSI enumerator before (even if that device is no longer present), you would not get that error and instead would get a handle to an empty set.  Likely the systems you see this succeed on have had a SCSI device present in the past, even if they no longer have it present.
    Tuesday, January 29, 2013 12:26 AM

All replies

  • Hello,

    Thanks for participating in MSDN forum.

    There is a specific forum for Windows driver related issue: Windows Hardware WDK and Driver Development We will move this thread to that forum. Your understanding will be appreciated.

    Regards,


    Damon Zheng
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, January 25, 2013 8:09 AM
  • First verify that your system has SCSI disks that are enumerated with SCSI.  Open the device manager and check the disk's hardware ID's under resources. 


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Friday, January 25, 2013 12:15 PM
  • I recommend you download both the binary and source to the DevCon utility and see if it reproduces your results:  http://msdn.microsoft.com/en-us/library/windows/hardware/ff544787(v=vs.85).aspx
     
    Also, how does the failing laptop show the disk in Device Manager?  The Setup and Device API’s are used by Device Manager, so whatever it’s doing, you can do too. 
     
    -- David

    Efficiently read and post to forums with newsreaders: http://communitybridge.codeplex.com
    Friday, January 25, 2013 5:02 PM
  • On all the systems that it succeeds, do any of them not have any devices with SCSI as the enumerator?  For windows 7, I believe what you are seeing is expected when the system has no devices that belong to the specified enumerator.

    Friday, January 25, 2013 7:13 PM
  • Jason (et. al.),

    Since you've all nearly suggested the same things, I'll reply to only one.  The first thing is, thank you for the replies.  The suggestion for using devcon to reproduce is a good one.  I hadn't thought of that.

    I'm not sure I worded this correctly in my original post but I don't see this behavior on my development, or many, many, others which also have no SCSI drives installed.  Just looked at my Device Manager again and there are no SCSI drives installed.  It would make sense that, if no hardware is "present", SetupDiGetClassDevs() would not return an error but would return a handle to an empty set.  In fact, this is what I usually see.  That is, SetupDiGetClassDevs() succeeds and when I call SetupDiEnumClassDevs(), it fails and GetLastError() returns ERROR_NO_MORE_ITEMS (or some #define very similarly worded).  This error from SetupDiGetClassDevs() telling me, ERROR_INVALID_DATA is entirely unexpected.

    Thanks, Andy


    Monday, January 28, 2013 9:21 PM
  • For windows 7, if the system has never seen a device under the SCSI enumerator before, the error you are seeing is expected.  If the system has ever seen a device under the SCSI enumerator before (even if that device is no longer present), you would not get that error and instead would get a handle to an empty set.  Likely the systems you see this succeed on have had a SCSI device present in the past, even if they no longer have it present.
    Tuesday, January 29, 2013 12:26 AM
  • Jason,

    Sorry for the late reply.  Things are quite hectic at work for the moment.  Thank you for the insight.  This is exactly what I was hoping someone would know.  Although I would still consider this unexpected behavior, simply given how the functions are documented and simply using them, this is good to know.

    Andy

    P.S. I'm curious ... I've always considered the [MSFT] in signatures, such as yours, mean that you work for Microsoft.  Is this assumption correct?

    Wednesday, January 30, 2013 6:51 PM
  • Yes, that assumption is correct.

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Wednesday, January 30, 2013 8:08 PM