Doesn't work with Dell Latitude E6400 Built-In SD Card Reader

I'd be interested in knowing how the built in readers report their drives. The drive has to report as "Removable" or "on the USB port" in order for imagewriter to recognize it. I could provide you with acustom build that logged some info, if you'd be willing to run it. Then I could look at that and see if anything jumps out at me.

There's also a known issue with multi-card readers - a multi-card reader was showing ALL of it's slots in ImageWriter, whether they were empty or not. So, I added a check that verified that the drive was "writable" before adding it to the device list. This meant that cards inserted *after* IW was already running weren't getting recognized (windows didn't "notify" about media insertion the way it does with a "standard" USB port), but if IW was started with the media already in the drive, it showed up in the device list.

There used to be a "refresh" button that would look for new media - I took that out when I added the automatic detection of insertion/ejection, but maybe I should put it back for cases like this. The problem with that is, if IW doesn't recognize the media even if it's available when IW is started, then the refresh button won't help.

I'm seeing exactly the same problem on my Dell Inspiron 1420, running Vista32 Home Premium. The SD Card reader shows in Windows Explorer as type "Removable Disk" but its drive letter doesn't appear in the dropdown. The only drive letter that does appear in the dropdown is the one for my USB external hard drive, which Explorer calls type "Local Disk." (Two other "Local Disk" drives, which are built in, not USB, do not appear in the dropdown.)

Having the same problem with an Asus laptop.
I also tried flashnul and that does work fine.

flashnul does detect it as removable drive.
One thing I did notice is that it does print out a warning that the device does not support a IOCTL_STORAGE_QUERY_PROPERTY call.
Are you perhaps also using that in the win32-image-writer code, and not taking into account that it might not be available on some devices?

==
D:\raspberry>flashnul G: -L berryterminal.img
C:\WINDOWS\flashnul.conf: No such file or directory
GetFreeDiskSpaceEx() failed: Access is denied.
DeviceIOControl() / IOCTL_STORAGE_QUERY_PROPERTY (adapter) failed: Incorrect fun
ction.

Disk G: (UNC name: \\.\G:)
------------------------------------------------------------[Drive geometry]--
Cylinders/heads/sectors = 1/255/63
Bytes per sector = 512
CHS size = 8225280 (8032 kb)
---------------------------------------------------------------[Device size]--
Device size = 1030101504 (982 Mb)
delta to near power of 2 = 43640320 (41 Mb), 4%
-----------------------------------------------[Adapter & Device properties]--
Removable device = Yes
Command Queue = Unsupported
--------------------------------------------------------------[Hotplug info]--
Device hotplug = Yes
Media hotplug = Yes

        Selected operation: load file content
        Selected drive: G:, 1030101504b (982 Mb)

        THIS OPERATION IS DESTRUCTIVE!!!
        Type 'yes' to confirm operation. All other text will stop it.

        Really destroy data on drive G:? :yes

-----------------------------------------------------------------------[Log]--
Runing operation [load file content] for drive G:

Writing 0x95f0000 (150 Mb), 2325556 b/s
image load finished

----------------------------------------------------------[Operation result]--
passes: 1
errors: 0
write bytes: 157286400 (150 Mb)
avg. write speed: 2325602 (2271 kb/s)
max/min write speed: 0 (0 b/s) / 0 (0 b/s)

Press ENTER to exit.
==

YES! We use IOCTL_STORAGE_QUERY_PROPERTY, and if it fails, we return the "something may be accessing the drive" error. Nice find.

I'm going to have to look into what I can do if that call fails - I didn't write the original code, but I also wasn't aware that the call may not be supported by some devices.

Thanks for the info....

Hmm, turns out I was wrong.
It is not IOCTL_STORAGE_QUERY_PROPERTY that is the problem, perhaps flashnul was querying a different property or something.

Instead it is IOCTL_STORAGE_CHECK_VERIFY2 that is the problem.
If I remove the following if statement it does show the drive and writes the image correctly:

==
if(DeviceIoControl (hDevice, IOCTL_STORAGE_CHECK_VERIFY2, NULL, 0, NULL, 0, &cbBytesReturned, (LPOVERLAPPED) NULL))
==

If I put a getLastError() after that function it returns 1 (invalid_function), so apparently the sd card reader doesn't support that function.

OK - interesting. That check is in there to verify that the device found
is accessible - there's a problem with multi-card readers where all the
devices will show in the device list, whether they have media in them or
not. Verifying that they were accessible handled that problem, but
introduced a problem where ImageWriter doesn't get an "update" that media
was inserted into the multi-card reader if ImageWriter is already running.
The work-around for that is easy - insert the media prior to starting
ImageWriter.

I'll have to see how else I can verify accessibility. Thanks for testing
that - I haven't been able to reproduce this issue on my end.

On Tue, May 29, 2012 at 6:20 PM, Max
<email address hidden>wrote:

> Question #194026 on Image Writer changed:
> https://answers.launchpad.net/win32-image-writer/+question/194026
>
> Max posted a new comment:
> Hmm, turns out I was wrong.
> It is not IOCTL_STORAGE_QUERY_PROPERTY that is the problem, perhaps
> flashnul was querying a different property or something.
>
> Instead it is IOCTL_STORAGE_CHECK_VERIFY2 that is the problem.
> If I remove the following if statement it does show the drive and writes
> the image correctly:
>
> ==
> if(DeviceIoControl (hDevice, IOCTL_STORAGE_CHECK_VERIFY2, NULL, 0, NULL,
> 0, &cbBytesReturned, (LPOVERLAPPED) NULL))
> ==
>
> If I put a getLastError() after that function it returns 1
> (invalid_function), so apparently the sd card reader doesn't support
> that function.
>
> --
> You received this question notification because you are a direct
> subscriber of the question.
>

Was wondering: what error code do the multi-card readers return if there is no media in the drive?
If it is NOT_READY or something else that is different than the INVALID_FUNCTION I'm getting, than perhaps you could test on that.

As in:

if(DeviceIoControl (hDevice, IOCTL_STORAGE_CHECK_VERIFY2, NULL, 0, NULL, 0, &cbBytesReturned, (LPOVERLAPPED) NULL) || GetLastError() == ERROR_INVALID_FUNCTION)

there's no error returned from the multi-card readers - they respond as a
device, and report as "removable", so they get loaded into the device list
(even though you can't actually write to them with no media). So, once
something shows as removable, I added a check to ensure that we could
actually write to it...

On Sat, Jun 2, 2012 at 6:35 PM, Max <email address hidden>wrote:

> Question #194026 on Image Writer changed:
> https://answers.launchpad.net/win32-image-writer/+question/194026
>
> Max posted a new comment:
> Was wondering: what error code do the multi-card readers return if there
> is no media in the drive?
> If it is NOT_READY or something else that is different than the
> INVALID_FUNCTION I'm getting, than perhaps you could test on that.
>
>
> As in:
>
> if(DeviceIoControl (hDevice, IOCTL_STORAGE_CHECK_VERIFY2, NULL, 0, NULL,
> 0, &cbBytesReturned, (LPOVERLAPPED) NULL) || GetLastError() ==
> ERROR_INVALID_FUNCTION)
>
> --
> You received this question notification because you are a direct
> subscriber of the question.
>

<< there's no error returned from the multi-card readers >>

You mean GetLastError() returns 0?

Your check looks like this:

==
// ensure that the drive is actually accessible
// multi-card hubs were reporting "removable" even when empty
DWORD cbBytesReturned;
if(DeviceIoControl (hDevice, IOCTL_STORAGE_CHECK_VERIFY2, NULL, 0, NULL, 0, &cbBytesReturned, (LPOVERLAPPED) NULL))
{
 *pid = deviceInfo.DeviceNumber;
  retVal = true;
}
==

On failure DeviceIoControl returns FALSE, and sets an error code you can retrieve with GetLastError( ).

For testing try:

==
// ensure that the drive is actually accessible
// multi-card hubs were reporting "removable" even when empty
DWORD cbBytesReturned;
if(DeviceIoControl (hDevice, IOCTL_STORAGE_CHECK_VERIFY2, NULL, 0, NULL, 0, &cbBytesReturned, (LPOVERLAPPED) NULL))
{
 *pid = deviceInfo.DeviceNumber;
  retVal = true;
}
else
{
      qDebug() << "Error code set by DeviceIoControl:" << GetLastError( );
}
==

(and add #include <QDebug> to the top).

What error code does it report in the debugging output when you use a multi-card reader?

My laptop returns 1 (invalid function)
If you get something different than 1 with your multi-card reader, you could use GetLastError( ) to differentiate between the multi-card scenario, and people's internal laptop reader.

comment fyi.
Totally failed to find built-in reader under XPproSP3 with Release 0.6 (r46) with card inserted either before or after App started.
However,
Rolling back to Release 0.1 (r15) and device recognition works fine with card inserted before app runs.

This may now be fixed with v0.9. Please retry it and let me know. Sorry it took so long, without hardware to reproduce it we kind of have to guess at these issues. I managed to find a laptop at work that reproduces this issue under XP (Windows 7 works fine). With that, I was able to patch the SD detection code.

So, I had actually researched this issue a while ago (just haven't had any spare time to do any work on this). The issue is that Windows treats SD cards differently than USB Removable devices, with their own set of APIs and everything. Even a SD reader plugged into USB goes through this new API (the reader is detected via USB, hence why it even works for us). I have a system that I can reproduce this on now (Intel NUC).

I hope to get this resolved with the next release, but I do not know when that will be.