SD卡问题：同样的卡在经过多次Suspend/Resume后存储管理部分读到不同的ID值

tianhj2001

SD卡问题：同样的卡在经过多次Suspend/Resume后存储管理部分读到不同的ID值 [复制链接]

如题，在使用同样一张卡，并且在操作过程中卡始终是在设备中的。
在多次Suspend/Resume之后发现会出现通过IOCTL_DISK_GET_STORAGEID读到的ID和之前的不同。
那位曾经遇到过这类问题。

6562748

LZ在Suspend/resume操作的时候SD卡断电吗？
如果断电的话有可能是相当于进行了一次插拔操作

tylar

不可思义

gaoli.85

后续又发现了新的情况，在比较两个Store结构的时候使用下面的代码：
if (memcmp( pStore1->m_pStorageId, pStore2->m_pStorageId, dwSize1) != 0)
goto exit;
在这里发现memcmp的比较结果是不相等，但是这个pStore1->m_pStorageId的结构（STORAGE_IDENTIFICATION）
中的成员却都是相同的。

这个问题感觉是比较奇怪，之前一直是以为设置的PnpDelayTimeOut值太小了。
看来这个还需要再仔细Debug一下

zhang12

帖子沉的好快。
目前在驱动部分发现了一个有可能导致这个问题发生的地方，看代码：
pDstOffset += sprintf( pDstOffset, "%02X\0", pMemCard->CIDRegister.ManufacturerID );
sprintf( pDstOffset, "%08X\0", pMemCard->CIDRegister.ProductSerialNumber );其中pDstOffset指向的是UCHAR类型长度12的数组，
pMemCard->CIDRegister.ManufacturerID是一个UCHAR变量；
pMemCard->CIDRegister.ProductSerialNumber是一个DWORD变量；
根据驱动部分的代码来看，意图是把ID和SerialNumber放在这个pDstOffset指向的数组中，
假设ID为0x18;SerialNumber为0x12345678;估计代码想在执行完之后有下面的形式：
1，8，'\0',1,2,3,4,5,6,7,8,'\0'。
可是通过上面的代码执行完之后呢，实际应该是：
1，8，1，2，3，4，5，6，7，8，'\0',XXX。
从上面的结果看，是代码在这里的偏移少了一个UCHAR的空间。而后果就是最后留下了一个XXX的数据。
这个数据就是数组分配时的初始值，如果没有给初始化值的话就不知道是个什么值了。那么就会在调用
Memcmp的时候返回不同了。而且看了这部分驱动的代码，确实是没有初始化这个Buffer。
上面的代码我利用VC验证过，的确有这种可能性。而且目前还没有在设备上得到验证。

各位高手请帮忙看看，有没有可能会是我提到的这种情况所导致的。
这里还有点疑问，就是这部分代码都是微软SDMEMORY部分的，我们也未做修改，如果真是由上面提到的所引发的
那么在项目上应该很早就会出这种问题，还是说这种情况几率非常小？对于内存管理这部分还没有仔细研究过，有
经验的高手能不能指点一下。
明天加班验证一下上面的疑点，希望运气好就是它。这样也能快点解掉这个BUG。

神童

你的问题，我一点都不懂，也来不及现场学习。
虽然是老好朋友了，但是只能顶了，惭愧。

5684326

你的问题，我一点都不懂，也来不及现场学习。
虽然是老好朋友了，但是只能顶了，惭愧。

zjwen

运气不错，通过在设备上调试的Debug信息发现果然是上面提到的地方出的问题。
正常情况下读到的ID为：02A3F66E89'\0'0;
而出现错误时为：02A3F66E89'\0'e。最后一个Byte变成e，由于最后一个Byte没有受代码的控制，
其值是由申请到这部分内存时该段内存本身的值决定的，同时在这里也没有做初始化动作。最后就导致了问题的发生。

从这次的Bug得到一个经验，在申请到内存时最好是要对这部分进行初始化，虽说如果算法正确的话没有初始化也不会
有问题产生，但是如果算法有漏洞，但是进行了初始化就可以很好的避开了。

xjtuwugang

顶！
看来微软的代码也是会有一些小bug的。

jwj

请问楼主：在多次Suspend/Resume之后，你的系统还能正常识别SD卡么？在你修改代码后呢？

liqingwu123456

还有一个问题：在你修改微软代码(目录..\COMMON\OAK\DRIVERS)后，编译步骤是不是需要与只修改CSP部分不同？谢谢