STVP/STM8S-Discovery崩溃了Windows

我希望我做的事情很愚蠢，但是如果我试图让STVP与我的STM8S-Discovery板通信它会导致Windows崩溃 - 崩溃报告说这是由于驱动程序故障。


我正在运行XP Pro SP3和STVP 3.1.3

我安装了STVP，然后将Discovery插入.STM8S-Discovery用户手册（UM0817）说：''当连接USB时，ST-Link的驱动程序会自动安装。''

Windows使用通用Microsoft驱动程序将设备配置为USB大容量存储设备，这不是我所期望的。虽然它确实包含3个STM网页的Internet快捷方式，但是显然有人希望它有时可以作为磁盘访问。

STM8S-Discovery运行Discover程序OK（当您触摸打击垫时，闪烁的绿色LED会改变速度），但是电路板的ST-Link部分没有任何活动迹象。

如果我尝试从设备读取任何内容 - 特别是UM0834第4部分中的选项字节：''开发和调试STM8S-DISCOVERY应用程序代码'' - Windows立即崩溃。

有什么建议么？

[此消息由以下人员编辑：smh于2009年11月30日01:12]



以下为原文




I hope I'm doing something stupid, but if I try to get STVP to communicate with my STM8S-Discovery board it crashes Windows - the crash report says it's due to a driver fault.


I'm running XP Pro SP3 and STVP 3.1.3

I installed STVP then plugged the Discovery in. The STM8S-Discovery User Manual (UM0817) says: ''The driver for ST-Link is installed automatically when the USB is connected.''

Windows configures the device as a USB mass-storage device using a generic Microsoft driver, which is not what I expected. Though it does contain 3 Internet shortcuts to STM web pages, so someone evidently expected it to be accessed as a disk sometimes.

The STM8S-Discovery runs the Discover program OK (flashing green LED changes speed when you touch the pad), but there's no sign of activity on the ST-Link part of the board.

If I try to read anything from the device - in particular the option bytes as per section 4 of UM0834: ''Developing and debugging your STM8S-DISCOVERY application code'' - Windows crashes immediately.

Any suggestions?

[ This message was edited by: smh on 30-11-2009 01:12 ]

也许我可以诱惑某人回答一些直接的问题：


有没有人用STVP成功运行STM8s-Discovery？
如果是，那么哪个驱动程序与设备相关联？ （您可以在Windows设备管理器中检查设备的属性）。
你是如何安装该驱动程序的？

我现在已经没有想法，因为我认为很有前途的小评估板甚至不够重，不足以成为一个好的镇纸！



以下为原文




Perhaps I can tempt someone to reply to some direct questions:

• Has anyone got an STM8s-Discovery running successfully with STVP?
  
• If so, what driver is associated with the device? (You can check the properties of the device in Windows Device Manager).
  
• How did you install that driver?
  
  I'm out of ideas at the moment and as things stand my promising little evaluation board is not even heavy enough to be a good paperweight!
  

很安静的板。我刚拿到了电路板，我设法编译了这个例子。据我所知，唯一的驱动程序是通用USB磁盘驱动程序。我没有安装任何东西。可能还有其他内容，但它未在Windows中注册。这来自远离专家的人，在linux或Mac上做这件事会更舒服。 BTW这是通过Mac上的VMWare在WinXP上运行的。


当它上传并与电路板通信时，LED像坚果一样闪烁，所以我知道它正在工作。



以下为原文




Pretty quiet board. I just got the board and I managed to compile the example. As far as I see the only driver is the generic USB disk driver. I did not install anything. There may be something else but it isn't registered in Windows. This comes from someone who is far from an expert and would be more comfortable doing this on linux or mac. BTW this is running on WinXP via VMWare on a Mac.


When it uploaded and communicated with the board the LED flashed like nuts so I know it was working.

感谢您的反馈。

我只是尝试了另一台计算机并且它正常通信 - 正如你所说的那样闪烁红色LED。
所以现在我必须弄清楚为什么我的主机崩溃如此可怕：两台机器都是XP Pro SP3 / AMD，据我所知，它们都使用相同的USB存储设备和磁盘驱动器驱动程序版本。



以下为原文




Thanks for the feedback.

I just tried on a different computer and it communicates OK - flashing red LED as you say.
So now I have to figure out why my main machine crashes so horribly: both machines are XP Pro SP3 / AMD and as far as I can see both are using the same driver versions for USB Storage Device and Disk Drive.

更多信息，以防ST的任何人感兴趣：


当他们尝试连接到设备时，STVP和STVD都会在我的机器上崩溃（从设备读取，开始调试等）
无论电路板是否连接到PC，都会发生崩溃。
解析崩溃转储文件可显示NVidia RAID驱动程序中发生的崩溃。 （我想这解释了为什么我的其他电脑没问题，因为它没有RAID）。
我昨晚升级到最新版本的NVidia驱动程序。崩溃继续，仍然在RAID驱动程序中，但在另一个地方。 （FWIW它看起来像是通过未初始化指针的内存引用）。
PC是稳定可靠的


因此，当他们搜索要连接的设备时，这些工具似乎正在做的事情足以让NVidia绊倒。

我可能会被困在这里，因为NVidia不太可能非常担心与相对不寻常的编程工具的兼容性，并且ST可能会声称该错误不在他们的代码中。

但是，我怀疑我可能不是唯一一个尝试在主板上安装NVidia芯片组的工具的人，所以值得ST看一下这个问题。如果有人想调查，我很乐意提供更多信息，或做其他测试。



以下为原文




A bit more info, in case anyone at ST is interested:

• Both STVP and STVD crash Windows on my machine when they try to connect to the device (Read from device, start debugging etc.)
  
• The crash happens whether or not the board is connected to the PC.
  
• Dissecting the crash dump files shows the crash happening in the NVidia RAID driver. (I guess this explains why my other PC is OK, since it doesn't have a RAID).
  
• I upgraded to the latest version of the NVidia drivers last night. The crash continues and is still in the RAID driver, but in a different place. (FWIW it looks like a memory reference through an uninitialised pointer).
  
• The PC is otherwise stable and reliable
  
  
  So it seems something that these tools are doing when they are searching for a device to connect to is enough to trip up NVidia.
  
  I could be trapped here, because NVidia is unlikely to be very worried about compatibility with comparatively unusual programming tools, and ST can probably claim that the bug is not in their code.
  
  However, I suspect I may not be the only person trying these tools who has an NVidia chipset on the motherboard, so it might be worth ST taking a look at the problem. If anyone wants to investigate I'd be happy to provide more information, or do other tests.
  

更多信息：


当您在STVD中开始调试时，它似乎使用命令行生成gdb7.exe：

gdb7.exe --quiet --command = swim gdbswim_stlink.ini

从命令shell发出此命令启动gdb确定

gdbswim_stlink.ini为gdb定义了四个用户命令：
仿真器复位口
仿真器，复位口，MCU
仿真器复位，热插拔，端口
仿真器，复位keepswim端口，MCU

并且gdb中的以下命令使Windows崩溃：
（gdb）emulator-reset-port 0

这是emulator-reset-port的定义：
码：

定义emulator-reset-port
target gdi -dll swimstm_swim.dll -stlink3 -port $ arg0


这会引入stm_swim.dll，后者又会加载STLinkIIIUSBDriver.dll

我猜STLinkIIIUSBDriver.dll正在搜索连接的磁盘以查找stlink设备，该搜索过程中的某些内容正在炸毁我的RAID驱动程序。

所以，如果我知道这个搜索是如何完成的，我可以编写一个小程序来重现问题并将错误报告给NVidia ......



以下为原文




A bit more info:


When you start debugging in STVD it appears to spawn gdb7.exe, with the command line:

gdb7.exe --quiet --command=swimgdbswim_stlink.ini

Issuing this command from a command shell starts up gdb OK

gdbswim_stlink.ini defines four user commands for gdb:
emulator-reset-port
emulator-reset-port-mcu
emulator-reset-hotplug-port
emulator-reset-keepswim-port-mcu

And the following command in gdb crashes Windows:
(gdb) emulator-reset-port 0

This is the definition of emulator-reset-port:
Code:



define emulator-reset-port
target gdi -dll swimstm_swim.dll -stlink3 -port $arg0


This pulls in stm_swim.dll, which in turn loads STLinkIIIUSBDriver.dll

I guess STLinkIIIUSBDriver.dll is searching through the attached disks to find an stlink device, and something in that search process is blowing up my RAID driver.

So, if I knew how this search is being done, I could write a small program to reproduce the problem and report the bug to NVidia...

你好。


到目前为止您已完成的故障排除工作非常出色！我对微控制器比较陌生，但在软件方面做了很多工作。这个论坛上的mod可能不希望我们深入了解他们的代码，但如果他们不愿意支持你作为客户，你应该能够自己排除故障并纠正问题。

在快速浏览一下你提到的DLL之后，只有8个命名导出，所以编写一个小垫片来记录它们被调用的函数，并且它们被调用的参数应该不会太麻烦。如果您正在使用windebug或其他基于Ring0的调试器，您可能能够断开功能并避免这种情况。

导出的功能确实用于枚举和打开存储设备。我提出的问题是，这可能不是Nvidia问题，而是STLINK函数将您的RAID控制器误认为是其他内容而打开/发送不受支持的调用或资源分配失败（因为它是错误的类型设备）并且没有错误检查以避免驱动程序中的空指针。

我建议填充USBDriver.dll并记录STMass_ *导出以确定最后的值和发生故障的函数。在这一点上可以进行修补，但是如果ST人员可以通过抛出文件的Debug版本来帮助你，以便能够避免编写中间DLL然后正确创建打补丁。



以下为原文




Hi there.


Great work with the troubleshooting that you've done so far! I'm relatively new to microcontrollers, but have worked in software quite a bit. The mods at this forum may not want us to go in-depth with hooking into their code, but if they are unwilling to support you as a customer, you should be able to troubleshoot and correct the issue yourself.

After taking a quick look at the DLL you mentioned, there are only 8 named exports, so writing a small shim to log the functions as they're called and the parameters they're called with shouldn't be too much trouble. If you're using windebug or another Ring0-based debugger you may be able to breakpoint the functions and avoid that.

The exported functions are indeed for enumerating and opening storage devices. The thing that I question is that this may not be an Nvidia problem, but instead the STLINK functions mistaking your RAID controller for something else and Opening/Sending an unsupported call or an allocation of the resource is failing (since it is the wrong type of device) and there is no error-checking to avoid a null-pointer in the driver.

I would suggest shimming the USBDriver.dll and logging the STMass_* exports to determine the last values and the function where the fault occurs. Patching in a work-around would be possible at that point, but it would be nice if the ST guys could facilitate this by throwing out a Debug version of the file for you to be able to avoid writing an intermediate DLL and then creating a properly patched build.

我使用windbg来追踪更多正在发生的事情。通过在加载STLinkIIIUSBDriver.dll时设置断点，我可以看到导出并在它们上设置断点，然后跟踪代码以查找告诉内核调用。


当STLinkIIIUSBDriver！STMass_SendCommand在D：驱动器上调用kernel32！DeviceIoControl时发生崩溃。它已经在C上完成了相同的过程：没有问题。 （C：和D：都是RAID磁盘上的分区）。

我现在正在尝试找出正在调用哪个DeviceIoControl函数。 dwIoControlCode = 0x000007a8。对于C：驱动器的同一调用的参数看起来有点怀疑，见下文，但调用成功。不幸的是，我没有抓住D调用的所有值：这一次。

在C上调用DeviceIoControl的参数：
码：

88 07 c3 00 handle（0x00c30788）＆lt; - 指的是 .C：
a8 07 00 00 dwIoControlCode（000-000007a8）＆lt; - 这是什么功能？
45 f9 12 00 lpInBuffer（0x0012f945）＆lt; - 有效数据存储器
88 13 00 00 nInBufferSize（5000）
01 06 f1 80 lpOutBuffer（0x08f10601）＆lt; - 垃圾？
00 00 00 00 nOutBufferSize 0x0
00 00 00 00 lpBytesReturned（NULL）
00 00 00 00 lpOverlapped（NULL）

MSDN说这关于lpOverlapped和lpBytesReturned：
''如果lpOverlapped为NULL，则lpBytesReturned不能为NULL。即使操作没有返回输出数据且lpOutBuffer为NULL，DeviceIoControl也会使用lpBytesReturned。在这样的操作之后，lpBytesReturned的值是无意义的''。

这是一个痛苦的过程，特别是因为运行程序太远会导致Windows崩溃，我不得不重新设置一切。请问，有没有来自ST听的人准备通过检查代码（甚至告诉我DeviceIoControl功能是什么帮助）或发布搜索ST-Link设备的codeefragment来使这项任务更容易一些？



以下为原文




I've used windbg to trace a bit more of what's going on. By setting a breakpoint when STLinkIIIUSBDriver.dll is loaded, I can see the exports and set breakpoints on them all, then trace into the code looking for tell-tale kernel calls.


The crash occurs when STLinkIIIUSBDriver!STMass_SendCommand calls kernel32!DeviceIoControl on the D: drive. It's already been through the same process on C: without problems. (C: and D: are both partitions on the RAID disk).

I'm now trying to work out which DeviceIoControl function is being called. dwIoControlCode = 0x000007a8. The parameters to the same call for the C: drive looked slightly suspect to me, see below, but the call succeeded. Unfortunately I didn't catch all the values on the call to D: this time round.

Parameters for DeviceIoControl call on C:
Code:



88 07 c3 00 handle (0x00c30788) <- refers to .C:
a8 07 00 00 dwIoControlCode (0×000007a8) <- what function is this?
45 f9 12 00 lpInBuffer (0x0012f945) <- valid data memory
88 13 00 00 nInBufferSize (5000)
01 06 f1 80 lpOutBuffer (0x08f10601) <- Garbage ?
00 00 00 00 nOutBufferSize 0x0
00 00 00 00 lpBytesReturned (NULL)
00 00 00 00 lpOverlapped (NULL)

MSDN says this about lpOverlapped and lpBytesReturned:
''If lpOverlapped is NULL, lpBytesReturned cannot be NULL. Even when an operation returns no output data and lpOutBuffer is NULL, DeviceIoControl makes use of lpBytesReturned. After such an operation, the value of lpBytesReturned is meaningless''.

This is a painful process, especially because running the program too far crashes Windows and I have to set everything up again. Please, is there someone from ST listening prepared to make this task a bit easier by checking over the code (even telling me what the DeviceIoControl function is would be a help) or publishing the codeefragment that is searching for the ST-Link device?

这很奇怪。


gdb reset-port命令是否仍然与您所说的相关：''无论电路板是否连接到PC，都会发生崩溃。 ''？

如果是这样，请从windbg开始在enum_getdevice函数（bp 10017945）上设置断点。切换电话，看看当电路板未连接时，eax是否返回0。 DLL中有关于各种IOCTL''错误'可能是什么的注释（查找''Cmd（stm_swim.dll中的status =''）。没有硬编码的调用带有您在USB驱动程序DLL，我可以直接看到，但如果枚举函数错误地报告你没有设备，我仍然会好奇。为什么''SendCommand''到一个不支持的设备？另外，如果你可以给在致命的DeviceIOControl调用中从堆栈返回eip，这也有帮助。

不过，我绝对同意ST应该对此进行故障排除。



以下为原文




That is very odd.


Does the gdb reset-port command still pertain to what you said with: ''The crash happens whether or not the board is connected to the PC. ''?

If so, have a go at setting a breakpoint on the enum_getdevice function (bp 10017945) from windbg. Step over the call and see if eax is returning 0 when the board's not connected. There are notes within the DLL for what the various IOCTL ''errors'' could be (look for ''Cmd (status ='' in stm_swim.dll). There are no hard-coded calls with the parameter that you posted in the USB Driver DLL that I could outright see, but I would still be curious if the enumeration function is erroneously reporting that you have a device when none is present. Why ''SendCommand'' to an unsupported device? Also, if you could give the return eip from the stack on the fatal DeviceIOControl call, that could help as well.

I absolutely agree that ST should facilitate troubleshooting this, however.

再次感谢您的投入。


我最近的所有测试都是在没有连接STM8S-Discovery的情况下完成的，因此无论设备是否存在，发出emulator-reset-port都会导致Windows崩溃。

windbg中的堆栈跟踪通常会在设置这些东西时进行融合，所以在我第一次运行时我错过了STMass_enum_getdevice的返回。是否有可能它在崩溃时没有返回，并且对DeviceIoControl的调用（从STMass_SendCommand调用）是enum_getdevice进程的一部分？

感谢有关stm_swim.dll中嵌入的消息的提示 - 我会更仔细地看看这些消息。但是，我从来没有看到任何这些消息显示，因为整个系统崩溃之前，任何东西都返回到stm_swim.dll中的函数



以下为原文




Thanks again for you input.


All my recent testing has been done without the STM8S-Discovery connected, so issuing the emulator-reset-port crashes Windows whether or not the device is present.

The stack trace in windbg is often cunfused while setpping this stuff so on my first run through I missed the return from STMass_enum_getdevice. Is it possible that it hadn't returned by the time it crashed and the calls to DeviceIoControl (called from STMass_SendCommand) are part of enum_getdevice process?

Thanks for the tip about the messages embedded in stm_swim.dll - I'll look more closely at these. However, I've never yet seen any of these messages displayed because the whole system crashes before anything is returned to functions in stm_swim.dll

哇..终于。这至少应该是有希望的。


“GetDriveTypeA”上的断点（从Kernel32导出）。

从跳转（shift-11）返回，它会引发你的注意：lea ecx，[ebp-0Ch] lea edx ..等等。稍微向下一步，你会看到一个需要0和3s as params（按0 推3 推0 推3）。

如果cmp esi，FFFFFFFF没有触发je，则推送参数并调用DeviceIOControl函数。

这是在Sendcommand中，从STMass_Enum_Reenumerate调用。 EIP 60aa9e上的参数值（这可能是不同的，因为它是一个DLL并且可能被重新定位）应该让您在系统死亡时确切地知道发送的内容。

如果可以确定这是导致失败的API调用，则可以将枚举之后的枚举实例化为快速且脏的补丁，以使其在您的系统上运行，直到制造商实际支持他们的产品。

---

我目前正在使用Windows 7 RTM，STVP工作正常。文件中有对大容量存储设备驱动程序的引用..看起来他们已经实现了自己的IO控制代码，将设备设置为不同的接收数据模式。

如果您的电路板已启动，您还可以更改GDB使用的ini（定义了emulator-reset-port命令）并添加'-SPY3（filename）'以获取一些相当详细的日志。不幸的是，有助于解决BSOD问题的程度是它会告诉你STMASS_ *的GetProcaddress / LoadLibrary有效。



以下为原文




Wow.. finally. This should be at least a bit promising.


Breakpoint on ''GetDriveTypeA'' (exports from Kernel32).

Do a return from the jump (shift-11) which should throw you onto: lea ecx, [ebp-0Ch] lea edx .. etc etc. Step-Over down a bit and you'll see a function that takes 0s and 3s as params (push 0 push 3 push 0 push 3).

If cmp esi, FFFFFFFF does not trigger the je, the params are pushed and the DeviceIOControl function gets called.

This is in Sendcommand, called from the STMass_Enum_Reenumerate. The value of the parameters at EIP 60aa9e (this could be different since it's a DLL and might be relocated) should let you know EXACTLY what is being sent the moment your system dies.

If it can be established that this is the API call that is causing the failure, it might be possible to instantiate the enumeration past the point of failure as a quick-and-dirty patch to get it working on your system until the manufacturer actually supports their product.

---

I'm using the Windows 7 RTM at the moment, and the STVP works fine. there are references in the files to the Mass Storage Device driver.. it just seems that they've implemented their own IO control codes to set the device to different modes of receiving data.

If your board were up, you can also change the ini that GDB uses (where the emulator-reset-port command is defined) and add ''-SPY3 (filename)'' to get some fairly verbose logs. Unfortunately, the extent that would help with the BSOD problem is that it would tell you that the GetProcaddress/LoadLibrary for STMASS_* worked.

这可能是一个很长的镜头，我为没有能够验证这一点而道歉，因为我没有发生故障的系统，但是这里有一个你可以尝试的补丁。我不能肯定地说这将解决问题，或者它是否仍然允许所有功能只能让你知道我的建议以及为什么我会这样做。


我能够抵消DeviceIOControl / GetDrive函数访问的驱动器号。将偏移量更改为+6会导致无法识别连接的设备（连接为''G：''）。将偏移量更改为+5意味着设备已连接，因此我相当确定这是按预期运行的。当然不是保证。


在stvd swim文件夹中（如果这可以修复问题，你需要更改stvp文件夹下的文件才能正常工作）：

十六进制编辑文件STLinkIIIUSBDriver.dll（我正在使用XVI32）。

要改变的补偿是：
19e01
19E47
19edc

在每个偏移量中，您应该看到此序列中的“41”字节：

83 C2 41

在所有3个地方改变41到46。如果您需要较低的驱动器号，则可能需要更低，如果下面有另一个冲突设备，则可能需要更高。

这种变化意味着：
83 C2 41 - 添加edx，41h

变为：

83 C2 46 - 添加edx，46h

这种方式的工作方式是有迭代器向计数器添加41h以获取要发送代码的驱动器号。更改值只意味着计数将开始更高，希望绕过导致问题的驱动器号。


如果您对此有任何疑问，请告诉我。



以下为原文




This could be a very long shot and I apologize for not having been able to verify this as I've no system where the failure occurs, but here's a patch that you can try. I can't say for certain that this will fix the issue or if it will still allow all of the functionality can only let you know what I propose and why I would do so.


I was able to offset the drive letter that the DeviceIOControl/GetDrive functions accesses. Changing the offset to +6 caused my connected device to not be recognized (which connects as ''G:''). Changing the offset to +5 means that the device does connect, so I am fairly certain that this is functioning as intended. No warranties, of course.


In the stvdswim folder (you'll need to change the file under the stvp folder for that to work if this fixes the problem):

Hex edit the file STLinkIIIUSBDriver.dll (I'm using XVI32).

The offsets to change are:
19e01
19E47
19edc

At each of these offsets, you should see the ''41'' byte in this sequence:

83 C2 41

Change 41 to 46 in all 3 places. It may need to be lower if you need a lower drive letter, or higher if there's another conflicting device below it.

That change will mean:
83 C2 41 -- add edx, 41h

becomes:

83 C2 46 -- add edx, 46h

The way this works is that there are iterators adding 41h to a counter to derive the drive letter to send codes to. Changing the value just means that the count will start higher, hopefully bypassing the drive letters that are causing the problem.


If you have any questions about this, please let me know.

太棒了 - 按照你的建议修补STLinkIIIUSBDriver.dll确实可以让stvd和stvp连接到主板。


由于我的RAID有C：和D：分区，我将0x41更改为0x45，因此设备搜索从驱动器E开始:( STM8S-Discovery连接为驱动器F :)。

我实际上在dll中发现了7个添加EDX的实例，41h，所以暂时我盲目地改变它们：显然需要更多的测试来确认我没有做任何损坏。

我改变的字节的偏移量是：
0x19e01
0x19e47
0x19edc
0x3b171
0x4d003
0x4d0e5
0x4e0b2

我还是想确切知道dll对RAID驱动程序做了什么让它崩溃，所以我将继续挖掘并添加任何有趣的东西。虽然驱动程序不应该崩溃，但我之前从来没有遇到任何问题，所以我仍然非常确定ST的设备枚举是做不应该做的事情。

哦，如果来自ST *的任何人正在倾听，那么输入你仍然会很高兴！

再次感谢您的帮助pdadev。



以下为原文




Fantastic - patching STLinkIIIUSBDriver.dll as you suggest does indeed enable both stvd and stvp to connect to the board.


Since my RAID has C: and D: partitions I changed 0x41 to 0x45, so the device search starts with drive E: (the STM8S-Discovery connects as drive F:).

I actually found 7 instances of add EDX,41h in the dll so for the time being I blindly changed them all: obviously a bit more testing is needed to confirm I haven't done any damage.

The offsets of the bytes I changed are:
0x19e01
0x19e47
0x19edc
0x3b171
0x4d003
0x4d0e5
0x4e0b2

I'd still like to confirm exactly what the dll is doing to the RAID driver to make it crash, so I'll continue digging and add anything interesting here. Although the driver ought not to crash I've never had problems with it before so I'm still pretty certain that ST's device enumeration is doing something it shouldn't.

Oh, and if anyone from ST *is* listening, it would still be nice to have your input!

Thanks again for your help pdadev.

没问题，我很高兴这对你有用！


您可能需要查看3b170更改，因为它是：
sub edx，41
添加edx，41

从它的外观来看，它是一种垃圾指令，但如果你正在改变它，你需要改变另一个（或者只是将它们两个都取出来）。其他调用可能是声音补丁，因为它们正在改变它提供给CreateFile / GetDriveType函数的内容，除非调用这些函数时初始驱动值是希望将数据发送给它的。

我确实认为应该进行正式修复，即使它是我们发现的重新实现。失败似乎是驱动程序在所有驱动器上发送自定义IOControl代码以找到电路板。可能的问题是IOControl代码，因为它们不像注册的CLSID那样重叠，并且ST使用的代码＃恰好匹配RAID控制器使用的东西。甚至像ST的技术人员一样简单地向您发送文件以记录GetDriveType返回的内容并跳过这些设备将比目前正在进行的更好。

无论如何，谢谢你的耐心等待。



以下为原文




No problem, I'm glad that it's working for you!


You may need to look at the 3b170 change because that's:
sub edx,41
add edx,41

Kind of a garbage instruction from the looks of it, but if you're changing one you'd need to change the other (or just nop both of them out). The other calls could be sound patches since they're changing what it fed into CreateFile/GetDriveType functions, unless those functions are called with the initial drive value being what is desired to have data sent to it.

I do think an official fix should be made, even if it's a reimplementation of what we've found. The failure seems to be that the driver is sending their custom IOControl codes at all drives to find the boards. The likely problem is that the IOControl codes, since they are not like CLSIDs that are registered, are overlapping and a code # that ST uses happens to match something that the RAID controller uses as well. Even something as simple as ST's techs sending you a file to log what GetDriveType returns and skipping those devices would be much better that what's currently going.

Anyhow, thanks for your patience.

当窗户崩溃时，我喜欢它。我在MAC OS下使用WIndows XP-SP3运行并行，并且您正在描述相同的蓝屏驱动程序故障。这对我的系统来说是一个很难的杀戮。我认为这可能是Mac / Parallels / XP驱动程序错误，但我猜你和你在同一条船上。我正在寻找解决方案并在下面提出一些好主意。谢谢



以下为原文




I love it when windows crashes. I am running parallels under MAC os with WIndows XP - SP3 and have the same blue screen driver fault you are describing. It is a hard kill to my system. I thought this may be a Mac/Parallels/XP driver error but guess I am in the same boat as you. I am looking for solutions and have some good ideas below. Thanks

我已经烧了很多午夜油，我承认我终于失去了继续的意志。 pdadev提出的修改可以解决这个问题，现在必须要做（BTW，虽然3b171上的补丁是不正确的，我认为它是无害的，因为它似乎是在Borland Visual Component库中的菜单处理代码，我想这不是实际使用）。


这个驱动程序在汇编程序级别是一项非常可怕的工作 - 我怀疑源代码也必须是可怕的。我无法抗拒一些评论，希望ST的某个人对他们的工作感到非常自豪，想要修复一些毫无疑问会破坏的东西。

我很确定pdadev是正确的，因为代码错误地将RAID磁盘识别为STM32设备，然后将用户定义的IoControl代码发送到RAID。尽管人们可能会争辩说NVIDIA驱动程序不会崩溃，但很可能这些代码与NVIDIA用于其自身目的的值相冲突，并且正在输入无效数据。 （回想一下崩溃是通过未初始化的指针进行内存访问）。

传递给我发现的deviceIoControl的函数代码是：
0x04D014 - 功能= 0x405：IOCTL_STORAGE_BREAK_RESERVATION
0x072008,0x222008 - 功能= 0x802：用户
0x07200C，0x22200C - 功能= 0x803：用户
0x072014 - 功能= 0x805：用户
0x07201C，0x22201C - 功能= 0x807：用户
0x072020,0x222020 - 功能= 0x808：用户

（Microsoft定义了0x000到0x7ff范围内的函数;用户函数的范围是0x800到0xfff）。

函数STMass_Enum_Reenumerate经历抽搐以尝试识别STM32设备。它首先显式调用GetDriveType，但在使用WINSETUPAPI中的函数枚举驱动器B到Z之前完全忽略了返回值（至少可以排除软盘和CD驱动器）。 A被跳过是因为看起来像是一个错误的错误。当我开始枚举每个设备的父母时，我担心我迷失在所有这些代码中。

我的猜测是，作者被MSDN使用GetDriveType吓跑了，它告诉你这不是识别USB驱动器的正确方法。这是因为USB连接的磁盘可能声称是DRIVE_FIXED或DRIVE_REMOVABLE，具体取决于所使用的介质（USB硬盘将声称固定，读卡器可移动;大多数USB笔驱动器显然声称也具有可移动介质）。实际上，STM32返回DRIVE_REMOVABLE：我相信这是设备的属性而不是驱动程序，但我不确定。

当然，有一种更简单，更可靠的方法来确定您自己的设备是否已插入机器？有：http：//www.codeproject.com/KB/system/RemoveDriveByLetter.aspx？msg = 2069695
在CodeProject上解释了如何识别USB磁盘，并且可以轻松调整演示代码以打印出包含供应商和设备ID的设备ID字符串，这应该是STM32的可靠指纹。

使用修改过的CodeProject演示，我发现RAID确实在STM32的枚举中出现了：

DeviceId = ACPI NVRAIDBUS 3＆amp; 267A616A＆amp; 0＆lt; - 这是RAID
DeviceId = USB VID_0483＆amp; PID_3744 5＆amp; 1A052CC6＆amp; 0＆amp; 6＆lt; - 这是STM32

但是，代码通过检查驱动器设备编号是否与卷设备编号匹配来安全地忽略它（阅读文章）。提供设备编号的DeviceIoControl功能也返回总线类型，确认设备是USB。看起来ST驱动程序没有进行额外的检查。

抱歉，如果我错过了驱动程序按原样写入的一些微妙原因，但上述方法似乎比使用用户定义的IoControl代码在机器上喷涂所有磁盘更安全，并希望它们不会造成伤害。



以下为原文




I've burnt quite a lot of midnight oil on this and I confess I've finally lost the will to continue. The modification proposed by pdadev does the trick and that will have to do for now (BTW, although the patch at 3b171 is incorrect I think it's harmless because it appears to be in menu handling code in the Borland Visual Component library which I imagine is not actually used).


This driver is a pretty horrible piece of work at the assembler level - I suspect the source must be grisly too. I can't resist a few comments, in the hope that someone at ST takes sufficient pride in their work to want to fix something that is undoubtedly broken.

I'm pretty sure pdadev is correct that the code is mis-identifying the RAID disk as the STM32 device, and is then sending user-defined IoControl codes to the RAID. Although one might argue that the NVIDIA driver shouldn't crash, it's quite possible that the codes clash with values used by NVIDIA for their own purposes and are being fed invalid data. (Recall the crash is a memory access through an uninitialised pointer).

The function codes passed to deviceIoControl that I found were:
0x04D014 - Function = 0x405 : IOCTL_STORAGE_BREAK_RESERVATION
0x072008, 0x222008 - Function = 0x802 : User
0x07200C, 0x22200C - Function = 0x803 : User
0x072014 - Function = 0x805 : User
0x07201C, 0x22201C - Function = 0x807 : User
0x072020, 0x222020 - Function = 0x808 : User

(Microsoft defines functions in the range 0x000 to 0x7ff; user functions are in the range 0x800 to 0xfff).

The function STMass_Enum_Reenumerate goes through convulsions to try to identify the STM32 device. It starts with the obvious call to GetDriveType, but completely ignores the return value (which could at least exclude floppies and CD drives) before enumerating drives B to Z using functions from WINSETUPAPI. A is skipped because of something that looks suspiciously like an off-by-one error. I'm afraid I got lost in all this code when it started enumerating the parents of each device.

My guess is that the author was scared off using GetDriveType by MSDN, which tells you it's not the right way to identify USB drives. This is because USB-connected disks may claim to be DRIVE_FIXED or DRIVE_REMOVABLE, depending on the media used (A USB hard disk will claim to be fixed, a card reader removable; most USB pen drives apparently claim to have removable media too). Actually, the STM32 returns DRIVE_REMOVABLE: I believe this is a property of the device not the driver, but I'm not certain.

Surely there's an easier and more reliable way to find out if your own device is plugged into a machine? There is: http://www.codeproject.com/KB/system/RemoveDriveByLetter.aspx?msg=2069695
on CodeProject explains how to identify USB disks and the demo code is easily tweaked to print out the device ID string which contains the vendor and device IDs, which ought to be a reliable fingerprint for the STM32.

Using the modified CodeProject demo, I found that the RAID did indeed turn up in the enumeration of the STM32:

DeviceId=ACPINVRAIDBUS3&267A616A&0 <-- this is the RAID
DeviceId=USBVID_0483&PID_37445&1A052CC6&0&6 <-- this is the STM32

However, the code safely ignores it by checking that the drive device number matches the volume device number (read the article). The DeviceIoControl function that provides the device number also returns the Bus Type, which confirms the device is USB. It looks like the ST driver is not making this additional check.

Apologies if I'm missing some subtle reason why the driver is written the way it is, but the approach above seems much safer than spraying all the disks on a machine with user-defined IoControl codes and hoping they do no harm.