15,473
社区成员
发帖
与我相关
我的任务
分享关于监控usb插拔的一个问题
写了个监控usb插拔事件的dll。
在dll内部，使用windows api创建一个窗口，不显示，只是通过RegisterDeviceNotification使窗口监控 WM_DEVICECHANGE消息。
现在的问题是，如果再console程序中下使用dll无任何问题，在mfc的程序中使用dll，插拔时间的相应明显会很慢，尤其是拔出事件，至少10s才会响应。
几个问题
1、为何在在mfc中使用dll，插拔响应会很慢？
2、我想起一个解决方法，是创建线程来监控WM_DEVICECHANGE消息，但是RegisterDeviceNotification只能注册到窗口，不能注册到线程？是否有注册到线程的函数？
3、是否有其他的解决方法呢？
在dll内部，使用windows api创建一个窗口，不显示，只是通过RegisterDeviceNotification使窗口监控 WM_DEVICECHANGE消息。
现在的问题是，如果再console程序中下使用dll无任何问题，在mfc的程序中使用dll，插拔时间的相应明显会很慢，尤其是拔出事件，至少10s才会响应。
几个问题
1、为何在在mfc中使用dll，插拔响应会很慢？
2、我想起一个解决方法，是创建线程来监控WM_DEVICECHANGE消息，但是RegisterDeviceNotification只能注册到窗口，不能注册到线程？是否有注册到线程的函数？
3、是否有其他的解决方法呢？
...全文
请发表友善的回复…
发表回复
bidahai 2012-10-15
- 打赏
- 举报
我也遇到过这个问题，延时很大，当时也没有解决
wyx100 2012-10-15
- 打赏
- 举报
引用 4 楼 的回复:
楼主，我比较好奇
现在的问题是，如果再console程序中下使用dll无任何问题，在mfc的程序中使用dll，插拔时间的相应明显会很慢，尤其是拔出事件，至少10s才会响应。
你怎么加载DLL的？ 10秒才响应。。
loadlibrary 动态链接的
10s才响应，不是指加载dll 需要10s，而是指usb设备拔出后10s程序才返回“有usb设备拔出”。单步调试过，dll拦截wm_devicechange消息前会有很长时间的等待，进入wm_devicechange消息处理后，时间就没什么区别了
在console下调用dll就没有问题，响应很快
楼主，我比较好奇
现在的问题是，如果再console程序中下使用dll无任何问题，在mfc的程序中使用dll，插拔时间的相应明显会很慢，尤其是拔出事件，至少10s才会响应。
你怎么加载DLL的？ 10秒才响应。。
loadlibrary 动态链接的
10s才响应，不是指加载dll 需要10s，而是指usb设备拔出后10s程序才返回“有usb设备拔出”。单步调试过，dll拦截wm_devicechange消息前会有很长时间的等待，进入wm_devicechange消息处理后，时间就没什么区别了
在console下调用dll就没有问题，响应很快
ljdyp 2012-10-13
- 打赏
- 举报
把程序发出来让大家一起帮你想办法了，响应时间10S不看程序可能没办法知道为什么了
看不见的裂痕 2012-09-20
- 打赏
- 举报
loadlibrary 动态链接的
初始化就加载然后到整个程序结束的时候析构里面Free再看看效果呢？
初始化就加载然后到整个程序结束的时候析构里面Free再看看效果呢？
孟如庭 2012-09-20
- 打赏
- 举报
[Quote=引用 2 楼 的回复:]
为何在在mfc中使用dll，插拔响应会很慢？
你直接响应WM_DEVICECHANGE就行了，都不需要RegisterDeviceNotification了吧
[/Quote]
不RegisterDeviceNotification到窗口，窗口根本不响应WM_DEVICECHANGE
为何在在mfc中使用dll，插拔响应会很慢？
你直接响应WM_DEVICECHANGE就行了，都不需要RegisterDeviceNotification了吧
[/Quote]
不RegisterDeviceNotification到窗口，窗口根本不响应WM_DEVICECHANGE
孟如庭 2012-09-20
- 打赏
- 举报
[Quote=引用 5 楼 的回复:]
增加一些Log输出等来确定到底时间延时发生在什么地方，觉得可能跟你的MFC、DLL没什么关系，而是你其他代码有问题
[/Quote]
单步调试过，延时发生在，dll拦截wm_devicechange消息前，
进入wm_devicechange消息处理后，处理时间就没区别了
增加一些Log输出等来确定到底时间延时发生在什么地方，觉得可能跟你的MFC、DLL没什么关系，而是你其他代码有问题
[/Quote]
单步调试过，延时发生在，dll拦截wm_devicechange消息前，
进入wm_devicechange消息处理后，处理时间就没区别了
孟如庭 2012-09-20
- 打赏
- 举报
[Quote=引用 4 楼 的回复:]
楼主，我比较好奇
现在的问题是，如果再console程序中下使用dll无任何问题，在mfc的程序中使用dll，插拔时间的相应明显会很慢，尤其是拔出事件，至少10s才会响应。
你怎么加载DLL的？ 10秒才响应。。
[/Quote]
loadlibrary 动态链接的
10s才响应，不是指加载dll 需要10s，而是指usb设备拔出后10s程序才返回“有usb设备拔出”。单步调试过，dll拦截wm_devicechange消息前会有很长时间的等待，进入wm_devicechange消息处理后，时间就没什么区别了
在console下调用dll就没有问题，响应很快
楼主，我比较好奇
现在的问题是，如果再console程序中下使用dll无任何问题，在mfc的程序中使用dll，插拔时间的相应明显会很慢，尤其是拔出事件，至少10s才会响应。
你怎么加载DLL的？ 10秒才响应。。
[/Quote]
loadlibrary 动态链接的
10s才响应，不是指加载dll 需要10s，而是指usb设备拔出后10s程序才返回“有usb设备拔出”。单步调试过，dll拦截wm_devicechange消息前会有很长时间的等待，进入wm_devicechange消息处理后，时间就没什么区别了
在console下调用dll就没有问题，响应很快
孟如庭 2012-09-20
- 打赏
- 举报
我猜测问题可能是console本身是没有窗口的，而mfc本身带有一个窗口？
孟如庭 2012-09-20
- 打赏
- 举报
[Quote=引用 9 楼 的回复:]
loadlibrary 动态链接的
初始化就加载然后到整个程序结束的时候析构里面Free再看看效果呢？
[/Quote]
就是这样做的。
loadlibrary 动态链接的
初始化就加载然后到整个程序结束的时候析构里面Free再看看效果呢？
[/Quote]
就是这样做的。
oyljerry 2012-09-19
- 打赏
- 举报
增加一些Log输出等来确定到底时间延时发生在什么地方，觉得可能跟你的MFC、DLL没什么关系，而是你其他代码有问题
看不见的裂痕 2012-09-19
- 打赏
- 举报
楼主，我比较好奇
现在的问题是，如果再console程序中下使用dll无任何问题，在mfc的程序中使用dll，插拔时间的相应明显会很慢，尤其是拔出事件，至少10s才会响应。
你怎么加载DLL的？ 10秒才响应。。
现在的问题是，如果再console程序中下使用dll无任何问题，在mfc的程序中使用dll，插拔时间的相应明显会很慢，尤其是拔出事件，至少10s才会响应。
你怎么加载DLL的？ 10秒才响应。。
孟如庭 2012-09-19
- 打赏
- 举报
[Quote=引用 1 楼 的回复:]
用服务监听。RegisterDeviceNotification可发送消息至服务（DEVICE_NOTIFY_SERVICE_HANDLE
），在服务进程中处理SERVICE_CONTROL_DEVICEEVENT 即可。
[/Quote]
csdn说的这部分我没看懂。怎么建立一个服务去监听？
用服务监听。RegisterDeviceNotification可发送消息至服务（DEVICE_NOTIFY_SERVICE_HANDLE
），在服务进程中处理SERVICE_CONTROL_DEVICEEVENT 即可。
[/Quote]
csdn说的这部分我没看懂。怎么建立一个服务去监听？
Gloveing 2012-09-19
- 打赏
- 举报
为何在在mfc中使用dll，插拔响应会很慢？
你直接响应WM_DEVICECHANGE就行了，都不需要RegisterDeviceNotification了吧
你直接响应WM_DEVICECHANGE就行了，都不需要RegisterDeviceNotification了吧
有时我感觉真的好迷茫 2012-09-19
- 打赏
- 举报
用服务监听。RegisterDeviceNotification可发送消息至服务（DEVICE_NOTIFY_SERVICE_HANDLE
），在服务进程中处理SERVICE_CONTROL_DEVICEEVENT 即可。
），在服务进程中处理SERVICE_CONTROL_DEVICEEVENT 即可。
