I am writing a Windows device driver using WDF (KMDF) for a USB3 device that transfers data in large chunks at a time. I've written a user-level application that tests this functionality, and for the most part, things work.
The problem I encounter is this: I have found that when I force-close (CTRL+C from a cmd window) the application mid-transfer, the on-going data transfer at the time of cancel immediately stops and the host seems to simply stop communicating with that endpoint. I have observed this on a USB bus trace. The requests return in the function driver as "STATUS_CANCELLED"
I have looked at other similar third party devices and ran their test applications with their drivers on those devices and found that when I kill their test applications mid-data-transfer, the transfer completes before the application closes.
My question:
How/when does Windows decide to kill in-flight requests when applications are closed?
Is there any way to mark the request as "uncancelable"? I've scoured the documentation but found nothing that suggests I need to do something to keep requests from being cancelled behind the scenes mid-transfer.
Any insights appreciated, thanks.
It's not about the device driver; it's about the way the console application handles the Ctrl-C event. The console application must trap the Ctrl-C event, and wait for the transfer to finish before it exits.
Related
There is a jvm in a shared vm. Other developer may remote debugging by idea, and cause hang up at breakpoints.
In some reason, I need to continue the process.
I've programed an agent with jvmti, tried to receive breakpoint events for clearing them. But there are no events received.
What is the right way to receive setbreakpoint event? Or any other way to stop hangup from remote?
Thanks in advance.
In HotSpot JVM, can_generate_breakpoint_events is an exclusive capability - this means, only one JVM TI agent at a time may possess this capability.
The standard jdwp agent used for remote debugging is also a JVM TI agent. When it is loaded, no other JVM TI agent may acquire can_generate_breakpoint_events capability. As a result, your agent will not be able to set/clear breakpoints or receive breakpoint events.
What you may try to do is to modify the original libjdwp instead of trying to intercept breakpoint events in your separate agent. Or even simpler - forcibly close jdwp connections whenever you want to resume the suspended application.
I am looking for some mechanism that would switch USB device to failsoft mode when connection to the site is broken (i.e. browser crashed, user closed tab with the site that communicates to the device or simply network connection is down).
One of the option I can see is some kind of mechanism of sending keep-alives from browser to the device - unfortunately the only (simple) way of transferring data from browser I found is via CDC (which is using bulk transfer - that the slowest way of sending data). Is there any way to utilize interrupt transfer via WebUSB? Or maybe there is a better way than sending keep-alives to achieve desired behavior?
Currently I am focused on Windows 10.
What you want to do is set up your interface with two alternate settings. Alternate setting 0 can be the failsafe mode and is selected by default. When your app opens the device it can call selectAlternateInterface() to select alternate setting 1 which would be your active mode. The OS will automatically send a SET_ALTERNATE(0) command to your interface when you call close(), the page is closed, or the browser crashes.
I am working on an (console) application, which should be executed on startup and keeps running all the time in the background (executing something every 30 minutes).
How can I, in another (device) application, check if my console application is running (and start it if its not)?I am using VB.NET CF 2.0 and everything is being deployed on a device running WM 6.5
All the code examples I found where only available on the "standard" .NET.
There are several ways your "monitoring" app could work (and certainly more than I list here).
Use a named mutex (you'll have to P/Invoke it). The monitored app would create and hold it, and the monitoring app would periodically check to make sure it's held. If it's not held, the monitored app is no longer running.
Use the Toolhelp APIs. Have the monitoring app use the Toolhelp APIs to periodically enumerate the running processes. If the monitored app is not in the process list, it is not running.
Use a named event. The monitored app would have a background thread that periodically sets a named (watchdog) event. The monitoring app would wait on that event and if it fails to get the event in a certain time bound, the other app is either not running or has locked up.
Use a socket. Have the monitored app open a socket and listen on it. The monitor app would send a "ping" periodically to the monitored app. The monitored app would respond to the ping with an ack. If the monitoring app doesn't get an ack, the monitored app is either not running or is locked up
Use a window handle. The monitor app periodically P/Invokes GetWindow of FindWindow to find an always-present window in the monitored app - often by Form text. If the monitoring app can't find the Window, the monitored app is not running.
I'm developing an app which relies on C2DM to be notified of some new data to be fetched from a REST service. I have successfully implemented the C2DM android feature, but the behavior over Wifi is different from the connection over 3G. The messages are received instantly over 3G, but I have to manually turn Wifi off and on to have a "grace period" of ~1 min in which I receive them instantly.
My question is: Is there any way I can programmatically restart the connection, or trigger the notification fetch?
EDIT:
I've implemented an AsyncTask that periodically "reassociates" the connection to the access point (using WifiManager.reassociate()) every minute and a half. Not so sure about the correctness of this solution, though.
I've seen similar issues. It seems that under some circumstances C2DM messages are not delivered over wifi connections, when they are over 3G. On a related note I've also seen Android devices "drop" the push connection, so messages are not delivered (in my case the solution can be to put the device in airplane mode and then turn the network back on).
This reinforces the fact that all applications that use C2DM should be built so that even if push messaging fails, the app still works (even if messages/updates are slower because there's occasional polling to the server)
I wouldn't personally want to mess with the wifi connection as that's something that may cause problems for the user.
We have a program that uses QoS-sockets, our softphone application uses QoS for the RTP.
That application is normally left running, sometimes however it is restarted. (Stop, wait 300ms, start.)
We have found that when the softphone-application is stopped that the last one useing QoS on the server, so the RSVP QoS-service on windows is stopped as well.
When we restart our application the RSCP QoS-service normally starts really fast, however sometimes the service start takes a full 30 seconds, causing our application to start slowly as well.
Anyone know if I can configure the service not to stop each time?
The computer is Windows XP SP3, with Windows Firewall turned on. (Our application do have an exception in the firewall.)
Regards
Leif
In the end this was solved with a workaround.
In the main-application we now open a QoS-socket, which we keep open until the main-application ends. That way the RSVP service cannot be closed, since it's in use.
(I found that opening the socket without bind()-ing works, so we don't need any port.)