Is there a way to make my Windows Mobile 6.1 application react to system reset?
If it matters, I am using Compact Framework 3.5.
A system reset (i.e. a call to the kernel with IOCTL_HAL_REBOOT) goes through the power manager (well it should, the OEM might have opted otherwise but that would be rare). During the reset, the PM broadcasts a power manegment notification which you can requent to receive by calling the RequestPowerNotifications APIs. One of the last things the power manager does is goes single-threaded and calls all drivers' Xxx_PowerDown methods. The drivers at this point have the option of doing clean up, final flushing, etc. to get into a stable state and then the device restarts.
From an app perspective, the RequestPowerNotifications call is the only thing you can do. Be aware that the PM broadcasts the notification and just keeps on moving. It does not wait for anyone to complete any activity (like it does in calling Xxx_PowerDown). This often means that your application will never get the notification, or if it does you may only get the opportunity to run a couple lines of code (I think the most I've seen was about 4 lines). On a suspend/resume, the app code typically runs after you wake back up. With a reset, since RAM and processor are reset, you don't get that opportunity.
So, after that long-winded response, the short answer is that you might be able to get the notification, but even if you do it's unlikely you'll actually be able to do anything in response to it.
Related
I've got quite an abstract question. I'm working on a project that requires constant device communication. I'm integrating multiple devices onto an external processing unit with a touchpanel to execute certain methods. I.e. the "start videocall" button on the touchpanel activates a relay, turns a display-device, camera-device and microphone-device on, etc.
On the flipside, I'm also trying to monitor these devices. What status do they currently have? Are they enabled/disabled ? What input is the display device currently on?
So far, I've come up with two solutions to prevent a bottleneck in the communication where I'm constantly polling (i.e. every two to five seconds to keep an acurate and up-to-date status) the on-state and input-state of the display-device.
Make use of threading so I can enqueue the different commands and execute them async. By also reading the response async, all communication should be nicely spaced out but I'd have a very "busy" communication line, taking it's toll on the processing unit.
With the help of events have the display-device notify the processor of it's changed status. This would take a lot of stress off of the communication line, but I feel like this is very easily disrupted. If the device doesn't throw it's events correctly (or the events are missed out on) the monitored state does not correspond with the actual state.
I'm curious if there are other ways of going about this issue. As of now, I'm leaning towards the second one because it stresses the processing unit a whole lot less, I just feel like I should be building in a lot of safeguards to prevent an inacurate representation of the actual device-states.
The project runs in C# on .Net 3.5.
Polling works, but it isn't fun or optimal. Reactive is best but as you've mentioned there may be a hiccup insuring your still listening to to the device and not just standing by for nothing. In this situation it makes since to optimize both processes. Poll when you're waiting or haven't heard a response in so long and listen when your polling returns good info, passing the polling.
That said, you shouldn't worry about taxing the unit too much with polling on various threads. This sounds like a purpose device so as long as you're not running it hot or stressing it to max all the time then using your resources are perfectly fine.
I'm working on a Unity game that receives OSC messages from the Muse EEG headset. I've tried two 3rd party C# libraries to handle the OSC communication, UnityOSC and unity-OSC-receiver. Both implement the OSC communication with an underlying System.Net.Sockets.UdpClient. Everything is running smoothly on Windows, but on OSX, after a while, I just stop receiving messages every time. No exceptions or error messages, no indication of what went wrong at all, just silence.
My application roughly works as follows:
Start a thread that spawns a process that runs Muse-IO. This makes the headset start sending messages. After starting the process, this thread is just chilling on process.WaitforExit()
Another thread runs a while loop - not in MonoBehavior.Update(), that's not fast enough - that keeps receiving and processing OSC messages. In both libraries, this essentially boils down to calling UdpClient.Receive()
Game uses the processed messages in the normal Unity update cycle.
Some 120 to 140 seconds after the connection is initialized, the stream of messages just stops, and so far I haven't been able to figure out why. The connection indicator light on the headset stays on, but nothing indicates it's actually still sending data.
Things I've ruled out:
It's not because the number of messages or the size of the messages. If I modify the command to the headset to only send some categories of messages, cutting the total in half (from about 600/s to 300/s), the timeout still happens at the same time.
It's not the OSC library. I get the exact same results with both OSC libraries.
It's not the firewall. The firewall is off.
It's probably not the port being used by something else. I tried different ports with the same result.
It doesn't appear to be Muse's OSX driver. When I use their GUI to visualize the incoming data, it keeps receiving data for as long as I want.
I suspect that Mono, Unity or OSX might be shutting down (garbage-collecting?) the Muse-IO process or thread, because the time before the problem occurs seems to be pretty much constant regardless of what I try. But I'm unsure how to further diagnose, let alone fix this now. Any clues, suggestions or amazing solutions would be most welcome.
I found the cause.
After spawning the I/O process, the thread would do
print("Process started!");
process.PriorityClass = ProcessPriorityClass.High;
process.WaitforExit();
In hindsight, that print statement is really poorly placed, oh well. It worked fine on Windows. Changing process priority only requires admin privilege if you're increasing it to Realtime, according to the docs. Not so on Mac though. apparently setting it to High also requires elevated rights on OSX. The resulting exception was silent/undetected/uncaught because it happens outside the main thread.
Then, several minutes later, it seems the thread is garbage collected, including its child process, even though that's still running. That delay really threw me off, making me look for the cause in all the wrong places.
Lessons learned:
Be more careful with possible exceptions when multithreading,
Don't mess with process priority if you don't absolutely have to,
And never trust the docs.
I have an app that conducts an interactive exam session for students on pre-configured computers without an internet connection. The app records user input, system metrics, etc. during the exam and follows an incremental approach to saving this data so that a sudden crash or power outage does not destroy the session data for the entire exam.
The app serializes data every second to a new file with a time stamp and compiles everything together at the end of the session to mark it as an ATOMIC transaction. This works fine.
What I want to do is make the app more robust in responding to unexpected scenarios such as shutdown-initiation triggered by a UPS, the user themselves accidentally kicking the power down button (it happens), etc. Of course I understand that not much can be done if the OS crashes or the power line breaks.
What I am looking for is:
a comprehensive list of events to subscribe to such as shutdown initiation, battery level critical for laptops, etc.
How to subscribe to these events under .NET 4 (any language).
You can't do nothing with power off. Application.UnhandledException and Close will trap anything you have a vague chance at dealing with which would include a close signal from a soon to be exhausted battery, or a UPS kicking in.
I have written an application that is used company wide. A lot of users have the tendency to leave the application open 24-7. This application is under development constantly as the Marketing department's needs change. Most changes are minor but often times need to be implemented quickly. Salesmen are often away from their desks or on the phone, so an intercom announcement does not always do the trick. The application is housed on a network file share and shortcutted to.
What I envision is something like a message popping up something like "The program will exit for an update in five minutes, please save your changes now." Is there a way to display this message and kick them from the exe remotely? I thought of maybe just having a database value that it checks periodically to see if an update is pending, but that seems like a cheap hack to me.
Your database check is as good as any other; I personally would recommend polling some service to which it subscribes that would do the same thing. If your app connects directly to the database, however, you're probably better off making the check in the database.
You'd be best off going with a ClickOnce deployment method, however. That would require a major architectural change, but would be best in the long run, IMO.
Pity it's not a web application. Deployment would be a snap!
Anyhow what I'd do is this. Make the application log users out after several minutes of inactivity.
Two approaches to unsaved work. Do nothing and therefore they loose it if unsaved when they are inactive and it logs them out.
As they work, a local journal of changes is kept. When they are logged out due to inactivity, logging back will use the journal to open things back up as they were.
EDIT: To prevent users from using the old version. Write a database field with a version or build number. If running version < version in db field then refuse login, and/or restart program to load new image.
You can set up a central server that the .exe sends requests to to find out when updates are available.
I would recommend that you look into WCF as a framework for your solution; there are many great references for the framework as well as posts on sites like this one. You can probably spin up a separate thread in your application that checks for updates every X minutes.
As for your specific question, "Is there way to display this message and kick them from the exe remotely?", yes it is possible, but it is more feasible to make the program automatically query for the update.
If you want to shut them down for update remotely, then you have to know where they are on the network. If the program periodically contacts a central database, then there is no need for the server to know where the program is on the network, the program can automatically reach out to the server from wherever it is.
You could use a messaging system such as RabbitMQ, or any other one, and have the applications listen to a channel in the system. Then an administrative application could send a message to the user applications forcing them to shut down.
If the changes aren't breaking changes, you might want to look at something like ClickOnce which allows you to publish updates to applications while the users are running them, though users will be running old versions of the application until it restarts.
I didn't get what you got stuck on. Just create a timer, and on user interaction, reset the timer, to e.g. 5 minutes. Then, when the timer fires, show the message box, and create another timer, when that one fires, just kill the current process.
Rather tangential answer but if the issue is people leaving workstations up and logged on then take a look at something like nightwatchman from www.1e.com that powers down the PC after x period of inactivity. Sell it to your company as "doing your bit for the environment" and saving wasted electricity costs.
I know this is probably the canonical "It depends..." question but I'd appreciate any pointers as to where to start looking.
I have a client/server app talking over ethernet. In one computer I run the server and a client and on another just the client. One runs Vista and one runs XP. After an uptime of about 3 weeks the entire computer freezes and nothing works, not mouse, not keyboard, nothing -just power off. Every ten seconds the server sends a ping message to see if the clients are alive, other than that just a few small messages go back and forth every day.
I'm trying to find out if it's me causing it or something else. I've started a session and after a few days I thought I'd check for strange increases in memory use but beyond that I have very few ideas.
Some thoughts to consider:
You know the computer doesn't respond, but that doesn't mean it's hung. Does it respond to a ping?
Maybe the disk activity light is on all the time?
You say "no keyboard" - do you mean no caps lock or num lock lights?
Although the .NET application may be the only one you're running at the time, that does not imply it is the cause of the problem. Some background job could be doing it.
For example, I notice that Retrospect backup, when it is creating a snapshot, freezes the entire system for 10-15 minutes. I mean, no caps lock, the clock in the task bar doesn't update, no CTRL-ALT-DEL, can't type into an "Answer" text box in SO, nothing. It had nothing to do with what I was doing at the time, which was answering a question on SO.
After it came back, SO asked if I was a human. My feelings were hurt. ;-)
You could attach a kernel debugger to the OS. That way you should be able to inspect the state of the OS and your process even if the OS is completely unresponsive. (Unfortunately, it's a lot harder than just hitting "break" in VS. I suggest reading John Robbin's "Debugging Applications for .NET and Windows" before trying that.)
You could also try to create memory dumps of your application in regular intervals. You might have to do a little scripting for that, though. (usually, you'd create a dump with a keystroke, using a tool like userdump or adplus, but if the OS is not responding to keystrokes, that won't work.) That way, you know what state your process is in during or shortly before a hang.
This page: http://blogs.msdn.com/debuggingtoolbox/default.aspx is a good starting point for scripting WinDbg. (If you don't know what to do with a memory dump, I'd again suggest John Robbin's excellent book on debugging!)
Other than that, I can only think of standard debugging tricks: does the problem occur on every PC? Does it happen if there are no client requests? Does it happen sooner if there are more client requests? Does it happen sooner if there is less available physical memory? Try removing parts of your application (maybe on a separate server for testing) and see if the problem still occurs, and so on. Try running it in a VM so you can see if it uses the CPU, harddisk, or network during those "hangs".
This isn't going to be the answer, but I'd advise starting by checking your OS event logs and running a perfmon to keep track of memory, cpu usage etc.
Which computer freezes, the server or client? And what OSes are they running respectively?
As Daniel L noted, tight polling loops can really kill the CPU. If you can, change your code to use event handlers, it's a much more robust solution.
Finally, are you certain there's not a hardware problem on the freezing computer?