mfc通过USB读数据

[sparrow429]

用libusb-win32读取USB数据，USB数据可以读取，但是不稳定，USB会断开.用bushound监控，出现C0000030（endpoint HALTED）的错误，请问是什么原因啊

[red-fly]

没有搞过这个东西，不了解，帮你up 可以尝试看下是否带有什么错误号码或者什么事件，是否会有断开原因的标示，首先确定是usb设备主动断开的，还是windows主动断开的，或者是意外断开的

[xiaohuh421]

USB断开, 是因为确实是物理断开(比如USB线质量问题或者USB口接触不良), 那就是你自己要做异常处理. 如果是USB驱动不稳定, 那就要找驱动的问题了.

[sparrow429]

引用 4 楼 jszj 的回复:

没有搞过这个东西，不了解，帮你up 可以尝试看下是否带有什么错误号码或者什么事件，是否会有断开原因的标示，首先确定是usb设备主动断开的，还是windows主动断开的，或者是意外断开的

这个很难确定啊，在不断地读取数据过程中，USB就连接不上了，用bushound监控，出现C0000012和C0000030的错误提示

[sparrow429]

引用 5 楼 xiaohuh421 的回复:

USB断开, 是因为确实是物理断开(比如USB线质量问题或者USB口接触不良), 那就是你自己要做异常处理. 如果是USB驱动不稳定, 那就要找驱动的问题了.

关键不好确定是驱动还是硬件的问题

[red-fly]

http://blog.chinaunix.net/uid-29345848-id-4389994.html http://blog.csdn.net/rayna00/article/details/51555486 这两个贴子的内容是一样的，你可以参考一下其中的说明，说不定会有帮助

[red-fly]

上面的贴子中，“"babble"错误. 一个"babble"错误发生当端点接受数据多于端点的特定最大报文大小.已经超过设置的最大发送的报文长度了”，从这个描述看，应该是报文的格式没有搞好，这个要看下是usb设备发送的报文大小不对，还是windows向 usb设备发送的报文不对

[sparrow429]

引用 9 楼 jszj 的回复:

上面的贴子中，“"babble"错误. 一个"babble"错误发生当端点接受数据多于端点的特定最大报文大小.已经超过设置的最大发送的报文长度了”，从这个描述看，应该是报文的格式没有搞好，这个要看下是usb设备发送的报文大小不对，还是windows向 usb设备发送的报文不对

一个"babble"错误发生当端点接受数据多于端点的特定最大报文大小.已经超过设置的最大发送的报文长度了。 这句话的意思是端点缓存满了导致这个错误吗

[xiaohuh421]

硬件问题很好测试. 只需要换几台电脑, 换几个USB线, 换几个你的USB设备. 如果都出现相同的问题, 那就说明是你使用的驱动问题, 如果你的驱动程序是系统自带的, 那么说明是你使用的那个USB读取库的问题. 如果你使用USB读取库, 也可以确定没有问题. 那就是你自己使用和配置问题了.

[sparrow429]

大牛来啊...........................

[赵4老师]

崩溃的时候在弹出的对话框按相应按钮进入调试，按Alt+7键查看Call Stack即“调用堆栈”里面从上到下列出的对应从里层到外层的函数调用历史。双击某一行可将光标定位到此次调用的源代码或汇编指令处，看不懂时双击下一行，直到能看懂为止。 检查是否资源泄漏的办法之一： 在任务管理器 进程 查看 选择列 里面选择：内存使用、虚拟内存大小、句柄数、线程数、USER对象、GDI对象 让你的程序(进程)不退出,循环执行主流程很多遍，越多越好，比如1000000次甚至无限循环，记录以上各数值，再隔至少一小时，越长越好，比如一个月，再记录以上各数值。如果以上两组数值的差较大或随时间流逝不断增加，则铁定有对应资源的资源泄漏！ 搜“GDI泄露检测”

[sparrow429]

引用 2 楼 zhao4zhong1 的回复:

崩溃的时候在弹出的对话框按相应按钮进入调试，按Alt+7键查看Call Stack即“调用堆栈”里面从上到下列出的对应从里层到外层的函数调用历史。双击某一行可将光标定位到此次调用的源代码或汇编指令处，看不懂时双击下一行，直到能看懂为止。 检查是否资源泄漏的办法之一： 在任务管理器 进程 查看 选择列 里面选择：内存使用、虚拟内存大小、句柄数、线程数、USER对象、GDI对象 让你的程序(进程)不退出,循环执行主流程很多遍，越多越好，比如1000000次甚至无限循环，记录以上各数值，再隔至少一小时，越长越好，比如一个月，再记录以上各数值。如果以上两组数值的差较大或随时间流逝不断增加，则铁定有对应资源的资源泄漏！ 搜“GDI泄露检测”

引用 2 楼 zhao4zhong1 的回复:

崩溃的时候在弹出的对话框按相应按钮进入调试，按Alt+7键查看Call Stack即“调用堆栈”里面从上到下列出的对应从里层到外层的函数调用历史。双击某一行可将光标定位到此次调用的源代码或汇编指令处，看不懂时双击下一行，直到能看懂为止。 检查是否资源泄漏的办法之一： 在任务管理器 进程 查看 选择列 里面选择：内存使用、虚拟内存大小、句柄数、线程数、USER对象、GDI对象 让你的程序(进程)不退出,循环执行主流程很多遍，越多越好，比如1000000次甚至无限循环，记录以上各数值，再隔至少一小时，越长越好，比如一个月，再记录以上各数值。如果以上两组数值的差较大或随时间流逝不断增加，则铁定有对应资源的资源泄漏！ 搜“GDI泄露检测”

软件没死啊，是检测到USB断开了

[zgl7903]

不知道你用的什么USB设备， 可以先排除是否是硬件问题, 一般的USB芯片 会有SDK， 可以烧录一个回环的firmware, 然后使用SDK中的上位机程序测试， 如果OK，那就是软件的问题（再区分是上位机问题 还是firmware 问题）， 如果有问题先解决硬件问题

[red-fly]

引用 10 楼 sparrow429 的回复:

[quote=引用 9 楼 jszj 的回复:] 上面的贴子中，“"babble"错误. 一个"babble"错误发生当端点接受数据多于端点的特定最大报文大小.已经超过设置的最大发送的报文长度了”，从这个描述看，应该是报文的格式没有搞好，这个要看下是usb设备发送的报文大小不对，还是windows向 usb设备发送的报文不对

一个"babble"错误发生当端点接受数据多于端点的特定最大报文大小.已经超过设置的最大发送的报文长度了。 这句话的意思是端点缓存满了导致这个错误吗[/quote] 这是一个线索，有四种情况： 1. usb设备端发送的报文组包有问题 2. windows端发送的报文组包有问题 3. usb设备端接收报文有问题 4. windows端接收报文有问题 对于接收，可能涉及到内存的大小，比如分配的内存过小，而过来的报文超过了它的大小导致异常发生。 但从描述上来理解，我更倾向于前两种情况

[sparrow429]

引用 11 楼 xiaohuh421 的回复:

硬件问题很好测试. 只需要换几台电脑, 换几个USB线, 换几个你的USB设备. 如果都出现相同的问题, 那就说明是你使用的驱动问题, 如果你的驱动程序是系统自带的, 那么说明是你使用的那个USB读取库的问题. 如果你使用USB读取库, 也可以确定没有问题. 那就是你自己使用和配置问题了.

库应该没有问题，用的是libusb，我怀疑是硬件的问题，但不知道怎么测试。。

[汪宁宇]

用USB监控 Bus Hound 看看是哪边关掉了

[xiaohuh421]

硬件问题很好测试. 只需要换几台电脑, 换几个USB线, 换几个你的USB设备.

[sparrow429]

引用 15 楼 xiaohuh421 的回复:

硬件问题很好测试. 只需要换几台电脑, 换几个USB线, 换几个你的USB设备.

换电脑什么的都没用，都是会断开的

[sparrow429]

引用 16 楼 wangningyu 的回复:

用USB监控 Bus Hound 看看是哪边关掉了

这个怎么看哪边关掉了，我监控了，错误提示是C0000012和C000030

[xiaohuh421]

换电脑, 换USB线, 换你自己的USB硬件设备都没有用的话. 这就要怀疑是你那个USB设备中的固件程序有问题了.