After intensive searching why certain workstations wouldn't perform a certain action when just being started up in the morning (...) I've discovered that GetPrivateProfileInt just returns the default value and doesn't bother to set GetLastError to something non-zero when the network-subsystem hasn't activated yet (e.g. because the DHCP client is still trying to get hold of an IP address to use.)
Does this sound familiar to someone? Does anybody happen to know what I should/could do about it?
For now I'll correct by using an alternate default value, and stalling a bit while I get my default value.
GetPrivateProfileInt() is one of those innocent looking Windows API functions that has a ton of code behind it. There's a mass of appcompat code, designed to allow Win3 programs to run on modern versions of Windows. One of the side-effects is that it is incredibly slow, it took about 50 msec the last time I profiled it.
Looks like you found a flaw in it. For all I know, it might actually be designed appcompat behavior. Emulating the way this API worked 18 years ago. I have no clue of course if that's accurate.
The very best thing you can do is stop using it. A possible workaround is to open the file first so that your program blocks until the service is up and running.
I would check if the file exists and sleep for a few seconds until the file is there. After some number of tries either use the default value or take an appropriate action.
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.
Every now and then, my sleeping disk wakes up, does what sounds like a single read, and then sits idle until it falls asleep again. Sometimes a program that I am using completely freezes for about 10 seconds while the disk spins up, even though that program doesn't seem to need to read from that drive.
Is there an api for listening to file accesses as they happen, or similar, so I can figure out what is read from that drive, so I can move it? If not on Windows, can I do this on Linux?
This is also applicable for figuring out what files/folders a program is accessing in general, so I wouldn't say it only applies to my very narrow problem.
There's a simple tool called What's My Computer Doing? that you can use to get a quick idea of what's causing activity on your computer.
Install and run it, and leave it running in the background. Once you use this tool to narrow down which process is causing the disk activity, you'll want a more comprehensive tool. I use Process Monitor from Sysinternals/Microsoft.
It can be a bit daunting at first, but that's mainly because it is so powerful. It can also alter the behavior of the computer. When it's running, it backs up the huge quantity of data it collects to the disk. So that's why I suggest using the 'What's My Computer Doing?' tool first. Once you know which process is generating the disk access you can add a new filter rule (keep all the defaults, as they mask out a bunch of normal system processes) and select "Process Name" "is" "process_name", or select "PID" "is" "actual_PID".
There are plenty of tutorials like this one that can help you get started with Process Monitor.
When my Windows 10 app runs, it causes a process called Runtime Broker to execute, which takes up a lot of Memory space.
I know my app isn't "Memory-hungry" and it hardly takes 80 MB of RAM to execute. But from the time it starts, the Memory used by Runtime Broker keeps in increasing until the PC gets stuck.
Upon killing that process, the app is force closed by Windows.
I would have posted my source code here, if only I knew which part of the code is causing this to happen.
What are the possible technical reasons for this problem to happen, and what are the possible fixes in my code to prevent this?
Is there something wrong with my code, or is it some API that I am calling?
You can easily delete RuntimeBroker.exe and any other file. I deleted RuntimeBroker.exe and Livecomm.exe by booting a live Linux Dvd and after loading go and mount the c: drive then simply navigate to the file and delete it. Done!
Runtimebroker seems to hold about 60k per file held via StorageFile objects. It's still a bad problem and the only solution is to not hold on to very many of these.
Microsoft just never does anything about this.
Update: Microsoft seems to have quietly ditched UWP. The replacement has "WinUI" and is probably called the Windows App SDK at the moment. No more runtimebroker.exe.
I saw this question in a forum about how an application can be developed that can keep track of the installation date and show trial period expired after 30 days of usage. The only constraint is not to use the external storage of any kind.
Question: How to achieve this?
Thanks
Bala
--Edit
I think its easy to figure out the place to insert a question work. Anyway, I will write the question clearly. "external storage" means don't use any kind of storage like file, registry, network or anything. You only have your program.
Use the file-modified date of the file containing the program as the installation date.
I like Doug Currie's idea of the file-modification date. But if the application is downloaded from the web, every night at midnight it gets relinked with new initialized data containing the new expiration date. Then any binary downloaded that day expires on the date given.
If you like, sign the date with a private key so it can't be hacked. Include a public key in the app and decrypt the date. If not correctly signed, hasta la vista, baby.
I don't know if this is possible, as most work I've done has been with embedded systems in which I don't even need to touch the operating system. But would the following be possible?
When compiling your program, leave some extra space at the end (say, 8 bytes), all set to 0. When your application is run, it fetches those bytes and if they're all 0, replaces them with the current time (That's the part I'm not sure about. Does the OS let you do that? If not, there might be some work-arounds using multiple processes.), otherwise, if the time difference is greater than 30 days, it notifies the user that the trial period has ended.
Of course, that method would be vulnerable to resetting the system clock.
If you can't use any external storage at all (not even config files or anything like that), you would need to code it into the app itself so the app's main method (or some method) checks if the current date is less than some expiration date. Part of your installer could actually compile that code on the fly and then it would be set to the installation date. This could be easily defeated by reinstalling the app, but then again, it's not realistic to have no external storage either.
I think the only way to do this generally would be to have your application spawn something off in a separate process that would continue to run and keep track of the date/time even if the main application were closed. When it was restarted, it would then connect to the running process to see if the trial period had expired.
Of course, this would only work if the computer was never restarted and the user never hunted down your spawned process and killed it, which is pretty unlikely. If your application does not do anthing IO-related (file system, registry, something on the network etc.), then a simple restart will wipe away anything that you've done.
So, to summarize: it's not really possible.
Is there any "Boot session ID" or (reliable) "Boot timestamp"?
For an installation I need to detect that a scheduled reboot took place indeed.
I guess I could do a dummy MoveFileEx() with MOVEFILE_DELAY_UNTIL_REBOOT, but i did hope for something easier.
(We have to install a 3rd party package that sometimes behaves erratically after an repair/update. In that state, accessing the device may even lock up the system)
(Windows XP, Vista, 7)
For things like this, WMI (Windows Management Instrumentation) is often a good starting place. I know you can get current uptime directly through it, which may allow you to determine if a machine recently rebooted.
Here is a blog post with some code samples as well:
http://blogs.technet.com/heyscriptingguy/archive/2004/09/07/how-can-i-tell-if-a-server-has-rebooted.aspx
Depending on your implementation language, you probably just want to pull out the query code from the vbscript.
Apparently Windows has the equivalent of "uptime". Here's more info: http://support.microsoft.com/kb/555737
As I understand it, this should tell you how long ago the system was booted. Will that information solve your problem?
You could search the System event log for event 6009 from the EventLog source - this is the first event recorded after each reboot.
I think the best answer has already been given here: Find out if computer rebooted since the last time my program ran?
That seems to be the simplest way. Use GlobalFindAtom() to see if it exists and create it, with GlobalAddAtom(), if it doesn't. It will persist beyond the execution of your program. If your application runs again, and sees that the atom exists, then then it isn't the first run since reboot.
If the computer is restarted, then the atom won't exist, indicating that this is the first run of your program since the reboot.