I have a computer-based test that takes several hours to complete.
However, the test is timed-out at some point, because my PC "goes to sleep in one way or another".
This is possibly related to the fact that the test consists of two processes which communicate with each other via port, so I'm suspecting that perhaps networking is disabled in some way (even if it's completely "local networking").
I have disabled both screen turn off and sleep in the Settings "page", under Power & Sleep.
Still no luck, the screen is locked with a password at some point, which I suspect causes the test to stop running in the background.
I even followed a procedure that I found on the web to disable screen-lock via Regedit in something like 18 steps (why on earth did this company figure out that this is a reasonable user experience).
Is there a solution to this problem?
Found a (very hacky) solution:
If you keep all windows minimized, then the screen doesn't get locked.
What a great operating system, by such a great company!!!
Related
Recently installed AutoHotKey to remap some keys in order to play a video game. It seemed simple/attractive enough at first. Was not really sure of how it worked but found the .chm file in the download which states in the first line of Usage & Syntax/Using the program:
AutoHotkey doesn't do anything on its own; it needs a script to tell it what to do.
Sounds 'secure' enough to me. Seems like mature software. Maybe overkill (now I know it certainly was overkill) but let's just see how it works.
My remapping was simple enough: change the AWSD keys for the LEFT-UP-DOWN-RIGHT keys. Script syntax is simple enough, just used an example that comes with the install files. Works essentially as expected. Got an annoying pop up after playing the game for a bit from AutoHotKey saying "you've pressed mapped keys 600 times" or something like that. Which was only a little annoying, so I ignored it the first few times. The game I play is real time so getting a even a 5 second interruption while in a match would mean certain loss, so I decided to just disable the script and uninstall.
Lo and behold: when I stop the script, the keys continue to be remapped. Was there some background process running? Maybe. I rebooted only to find that on my Windows login screen my keys continue to be remapped. Huh? Did AHK mess with some registry bindings or something?
I do not know that much about how Windows works, but my vague recollection is that registry bindings is something is active once the OS is active. I search on the web for say 1 hour before I give up for the time being and I end up activating the script again in order to write normally. This works as expected and I literally forget about it until any time I have to reboot.
Honestly a minor annoyance, but due to the world changing very quickly I lately have very few precious minutes that I can actually sit down on my desktop, whereas I used to be able to spend hours on this type of computer issue in order to get to the bottom of it. In other words, my current solution felt good enough. But not anymore. I think something more serious and possibly nefarious may have occurred. I don't want to seem dramatic but I just discovered something else a few minutes ago.
I have a Linux installation on another drive and I just happened to want to load it up after my last Windows blue screen (have gotten a couple of those lately, literally 2 in the space of 2 days and this had maybe only ever happened once before, like 2 years ago, so I am a already concerned about a possible deeper issue). My firmware/bios has a password and guess what I found when I tried inputting it: the keys were still remapped.
At this point I am at a complete loss. I didn't even think this sort of thing was possible. Some OS level software caused a change that was able to be reflected on the bios? Did it affect the keyboard driver? A driver that both windows and the motherboard bios use?
What else have I tried or looked at:
Device Manager claims my Keyboard has 3 instances of "HID Keyboard device". Not entirely sure why it shows 3. Properties show it has 2 driver files: kbdclass.sys and kbdhid.sys, which I suppose are some standard drivers. Not sure how to proceed.
My keyboard is inland (cheapest i could find at microcenter) i am not sure why I cannot find the website for that company. Found some drivers on reddit but they are on some sysadmin's google drive. I will download that exe when i am desperate...
UPDATE
I 'solved' the issue bye getting another keyboard (an old IBM KB-0225) and everything is now in order. I tried disconnecting the Inland keyboard and reconnecting, but after reconnecting I was still experiencing the same issue.
I don't know if I should close this question as there is no longer an issue, but I would like to see if anyone has any other additional theory as to why some software/driver changed occurred inside a keyboard device. As far as I knew, these devices have not internal memory other than possibly some logic gates.
There must be a background process running.
to check that:
note : For windows 10
On your taskbar, click on the ^ button (skip this step if there is no such button)
right-click on the sign.
click on "exit"
If the above steps do not work, try keeping a watch all the time, to see if you notice something uncommon.
While I'm using my computer a blue window will pop up for a second then go away. The label said windows power shell, I've tried looking at the event viewer but I could not identify anything there since I'm a new user. What could be causing this?
Running windows 10
Sometimes installed programs open up command prompts to run services/init tasks, so its not completely unusual.
I've never seen it happen with powershell however.
it could be innocent and just a program you have installed running init behavior, but it could also be malicious.
the first thing to try is checking what programs are set to startup automatically. if there is a load of bloat, you could try turning off the unnecessary ones and see if it still happens.
but realistically the only real way forward is to get a good quality antivirus, and run a full system scan over your pc to double check. it wont give you 100% certainly as things could possibly get passed it, but realistically if it passes you should be fine
I have come across a Lenovo IdeaCentre A540-24ICB system with a scheduled task that wakes the computer to start my application and it seems to start but the system goes back to sleep right away. Sometimes it appears to not start (or goes to sleep so fast nothing is logged yet) so I checked the Windows power sleep options to ensure "Allow wake timers" was enabled but it didn't exist! Searching online I found a registry entry to add to have it show up in the power options and then ensured it's was enabled. However, didn't make a difference.
I have to use the mouse/keyboard for the computer to wake long enough to run the application (it will start where it left off). The application has been used for years and waking and running has worked. It already tells the system to not go to sleep through the api call in the main processing thread (which could take a fraction of a second to get to):
SetThreadExecutionState(ES_CONTINUOUS | ES_SYSTEM_REQUIRED);
I thought that API was enough to prevent system from going to sleep? As mentioned, it has worked for years. It's just this new Lenovo system or the Win10 installed with it doesn't seem to honor it? Is there some other API call that needs to be called? or any checks / fix the app should do to ensure the SetThreadExecutionState() will work?
TIA!!
Summary
When putting the monitor in sleep mode in Windows 10, Windows seems to execute some tasks that don't get executed with the screen on.
This is interfering with our software, and we need to get rid of it.
Ful story
For a hardware device with a touch screen, I need to be able to turn off the touch screen when it's not in use, for durability reasons. Windows has a message that you can send to turn it off, SC_MONITORPOWER. More specifically:
SendMessage(hwnd, WM_SYSCOMMAND, SC_MONITORPOWER, 2);
This works fine, but when the screen is off, Windows is apparently sometimes performing some tasks that it doesn't do when the screen is on. We are careful to never write anything to the screen in this situation (that causes huge problems when the screen is off, in fact just having a blinking cursor in a DOS box is using up half a core when the screen is off).
Our software requires a callback to be executed every 0.25 ms. We have turned nearly every task, service and several other things in Windows off, and with the screen on, I can run our software for days without ever missing a callback. But with the screen off I get hiccups. The callback already runs at the highest possible priority.
So there is apparently something that we missed when we turned all services and tasks off. There appear to be 2 causes of hiccups:
One happens once every 10-30 hours or so (not sure of the exact time, it seems to vary). But it always happens 5 times, with EXACTLY 5 minutes (at most a few milliseconds off) in between (so in total it happens 5 times in a 25 minute period).
Beside this, we get a single hiccup typically every 4-10 hours, but the time between occurrences doesn't seem to be very constant so there could also be multiple causes.
I'm a bit at a loss here, and running analysis software can easily interfere with our own software, making it harder to detect when these hiccups really occur and when they are caused by running the analysis software.
Interestingly, I have seen this 5-times-every-5-minutes thing also on a completely different system (different hardware, different OS version), when recording audio in Adobe Audition. Audition misses pieces of audio every 5 minutes in this case, and I think it also only happens when the monitor is in sleep mode and you're not logged in remotely.
We have already tried to turn the touch screen off using direct monitor commands like Nircmd does, and it doesn't support those. My guess is that the SC_MONITORPOWER message is triggering more things in Windows, and if we can turn them off, that would fix our problem. Any ideas?
System
Intel i5-8700 with 6 cores, Windows LTSB, no extra software installed except our own.
Never mind, problem solved. It was not an extra task that was being started, it was one of the existing Windows processes that for some reason only causes issues when the display is off. Since killing them is not an option (Windows will just restart them), I've suspended the following processes, and the culprit is one of these (I don't know which one yet):
sihost.exe
igfxEM.exe (I very much suspect this one)
RuntimeBroker.exe
dllhost.exe
taskhostw.exe
explorer.exe
I have to continue testing a bit longer to be absolutely certain, but so far with these tasks all suspended I've not seen a missed callback in the last 38 hours. I don't know yet if there are any drawbacks to suspending all these things, so I'll try to find the cause(s) and suspend only that/those.
Given that Outlook runs in most offices, and given that a screensaver may user CPU, or network file copies, or virus scans, or network installs by the admin (granted, that usually happens when you're logged out), and all the myriad other things that might occur on a Windows 7 desktop in an office environment, how could I possibly know that a user is idled out, and not just reading a PDF?
Do I use a set of metrics to sample at regular intervals and use that to determine "away" or do I need to monitor some file, is there a API that should be exposed?
I can't rely on screensavers being active, or the computer entering a specific power state, and I'm not sure what is exactly off-limits, but I also don't know what's on-limits, as it were.
I think you're looking for GetLastInputInfo, which tells you how long it's been since the user hit a key on the keyboard or wiggled the mouse (or touched a touch-enabled screen?).