Originally discovered the problem when playing content through
CEPlayer and found sometimes after removal of the SD card the player
would hang for roughly ~12 sec before exiting, the hang would be the
result of an IAsyncReader->SyncRead() call in that it would take ~12ms
to return with an error.

Further investigation determined the hang could be reproduced through
file explorer.

Normal scenario:
1) Insert SD Card, open file explorer, navigate to SD card contents.
2) Eject SD Card

File explorer exits in about ~4.5s in the debug build.

Log snippet (note that time between CStore::Destructor() and
GetModeInfoEx() is 134ms, GetModeInfoEx happens after file explorer
windows closes, presumably when it redraws desktop):
Unloaded symbols for 'C:\WINCE500\PBWORKSPACES\SDCARDTEST\RELDIR
\DB1200_MIPSII_DEBUG\SDMEMORY.DLL'
915405 0x87fe0a28: FSD_UnmountDisk(0xd3fe0): unmounting...
915405 0x87fe0a28: FATFS!UnmountDisk: unmounting all volumes on disk
000D3FE0
915443 0x87fe0a28: CStore Destructor(000D1FE0)
915577 0x87974238: GetModeInfoEx: modeId 0, width 1024, height 768,
bpp 16, format 4

Stall scenario:
1) Insert SD Card, open file explorer, navigate to SD card contents.
2) Eject SD Card, after its ejected click to highlight another file on
the SD Card at this point the file explorer window will hang and you
will not be able to select another file.

File explorer exits in about ~12.7s in the debug build.

Log snippet (note that time between CStore::Destructor() and
GetModeInfoEx() is 8365ms, GetModeInfoEx happens after file explorer
windows closes):
Unloaded symbols for 'C:\WINCE500\PBWORKSPACES\SDCARDTEST\RELDIR
\DB1200_MIPSII_DEBUG\SDMEMORY.DLL'
2485265 0x87fe0a28: FSD_UnmountDisk(0xd3420): unmounting...
2485265 0x87fe0a28: FATFS!UnmountDisk: unmounting all volumes on disk
000D3420
2485303 0x87fe0a28: CStore Destructor(000C54F0)
2493668 0x87974238: GetModeInfoEx: modeId 0, width 1024, height 768,
bpp 16, format 4

To summarize the problem seems to be that if a query is made to the SD
card after its ejected but before its finishes shutting down it will
create a ~8-12s stall. Normally this example with File Explorer would
be quite rare, but going back to the real issue where playing files
from the SD Card through CEPlayer, the DirectShow graph will be
constantly making read requests to the SD Card and if one is made at
the right time this stall occurs and the function IAsyncReader-
>SyncRead() will stall and not return for ~12ms giving the appearance
that the Media Player is hung.

Sometimes the IAsyncReader->SyncRead would not stall and immediately
return the error and as a result the player would be able to be exited
normally without the ~12s hang.

I was looking for suggestions on how to determine further what is
causing this delay or if anyone else has seen this issue before.

Thanks.

Re: SD Card removal and ~12s stall by K

K
Fri Jun 08 19:27:20 CDT 2007

You could try to fine tune the

PNPUnloadDelay value under
HKEY_LOCAL_MACHINE\System\StorageManager

And refer to this thread
http://groups.google.com/group/microsoft.public.windowsce.platbuilder/browse_thread/thread/8779040c3e015126/b32178153acf2a1b
or this document
http://msdn2.microsoft.com/en-us/library/aa912238.aspx

<embdev@comcast.net> wrote in message
news:1181331918.595443.41650@m36g2000hse.googlegroups.com...
> Originally discovered the problem when playing content through
> CEPlayer and found sometimes after removal of the SD card the player
> would hang for roughly ~12 sec before exiting, the hang would be the
> result of an IAsyncReader->SyncRead() call in that it would take ~12ms
> to return with an error.
>
> Further investigation determined the hang could be reproduced through
> file explorer.
>
> Normal scenario:
> 1) Insert SD Card, open file explorer, navigate to SD card contents.
> 2) Eject SD Card
>
> File explorer exits in about ~4.5s in the debug build.
>
> Log snippet (note that time between CStore::Destructor() and
> GetModeInfoEx() is 134ms, GetModeInfoEx happens after file explorer
> windows closes, presumably when it redraws desktop):
> Unloaded symbols for 'C:\WINCE500\PBWORKSPACES\SDCARDTEST\RELDIR
> \DB1200_MIPSII_DEBUG\SDMEMORY.DLL'
> 915405 0x87fe0a28: FSD_UnmountDisk(0xd3fe0): unmounting...
> 915405 0x87fe0a28: FATFS!UnmountDisk: unmounting all volumes on disk
> 000D3FE0
> 915443 0x87fe0a28: CStore Destructor(000D1FE0)
> 915577 0x87974238: GetModeInfoEx: modeId 0, width 1024, height 768,
> bpp 16, format 4
>
> Stall scenario:
> 1) Insert SD Card, open file explorer, navigate to SD card contents.
> 2) Eject SD Card, after its ejected click to highlight another file on
> the SD Card at this point the file explorer window will hang and you
> will not be able to select another file.
>
> File explorer exits in about ~12.7s in the debug build.
>
> Log snippet (note that time between CStore::Destructor() and
> GetModeInfoEx() is 8365ms, GetModeInfoEx happens after file explorer
> windows closes):
> Unloaded symbols for 'C:\WINCE500\PBWORKSPACES\SDCARDTEST\RELDIR
> \DB1200_MIPSII_DEBUG\SDMEMORY.DLL'
> 2485265 0x87fe0a28: FSD_UnmountDisk(0xd3420): unmounting...
> 2485265 0x87fe0a28: FATFS!UnmountDisk: unmounting all volumes on disk
> 000D3420
> 2485303 0x87fe0a28: CStore Destructor(000C54F0)
> 2493668 0x87974238: GetModeInfoEx: modeId 0, width 1024, height 768,
> bpp 16, format 4
>
> To summarize the problem seems to be that if a query is made to the SD
> card after its ejected but before its finishes shutting down it will
> create a ~8-12s stall. Normally this example with File Explorer would
> be quite rare, but going back to the real issue where playing files
> from the SD Card through CEPlayer, the DirectShow graph will be
> constantly making read requests to the SD Card and if one is made at
> the right time this stall occurs and the function IAsyncReader-
>>SyncRead() will stall and not return for ~12ms giving the appearance
> that the Media Player is hung.
>
> Sometimes the IAsyncReader->SyncRead would not stall and immediately
> return the error and as a result the player would be able to be exited
> normally without the ~12s hang.
>
> I was looking for suggestions on how to determine further what is
> causing this delay or if anyone else has seen this issue before.
>
> Thanks.
>