I'm using a wireless modem program from my ISP. This program automatically disconnect when it detects the line is idle. It does so in 2-5 minutes of idle time. Whenever I reconnect, It will automatically fire up my default browser to the ISP portal. I DID NOT pay them to shove their web portal in my face 50 times a day. The ISP provides no options for disabling this behavior. Can someone please show me how to hex edit the EXE program to stop it from annoying the hell out of me?
If thats the route you want to take then find a free hex editor for your system from : http://en.wikipedia.org/wiki/Comparison_of_hex_editors
And then search for hints. If it's obvious then you may be able to do something. Then again maybe not.
You can also look for programs that specifically deal with this annoyance, for example programs that do a network request every so often to keep the connection active.
If possible, try starting the program as another user, and deny this user read/execute access to your default browser's exe file.
Related
This just started happening for no good reason I can find.
If I launch the MSACCESS.EXE program, then open a database. The database opens within 1 second.
If I launch the same database by double-clicking on the .accdb file's icon. It takes about 40 seconds for the Access window to appear, and less than 1 second after that the database opens.
The database is local, and both Access and the DB are on an SSD. The system is an Asus Z97 motherboard, i7-4790K # 4MHz (not overclocked) with 32gb RAM and about 200gb of free hard disk space.
In both cases, performance after opening is excellent with no issues. It appears it's only the launching of MSACCESS.EXE by double-clicking a .accdb file that is affected. I double-checked the file association for .accdb and it points to the correct executable.
I captured some data with Performance Monitor during the 40-second pause. MSACCESS.EXE is using about 0.4% CPU, doing almost no disk I/O, and there's no network activity.
I've already tried "Compact and Repair" but that had no effect.
This just started happening, and now seems to be affecting Access on ALL .accdb files. They open instantly from within Access but take 40 seconds to open when double-clicked. I haven't installed any new software or Windows updates recently.
Curiously, if I change the .accdb extension to .accdr (runs the db in the client runtime instead of full Access) the database will launch instantly.
What could possibly be going on here? I've searched the web and found some posts having to do with databases on a network share, but that doesn't apply here.
For anyone else encountering this issue, it appears this bug has nothing to do with Access specifically.
I needed to shutdown the machine, and when I did so, Windows seemed to completely ignore multiple shutdown requests. As I was googling to troubleshoot, after about 10 minutes, the shutdown did finally start. It took another 10 minutes to shutdown.
After rebooting the slow launch problem no longer occurs, there's only about a 2 second delay, which I assume is just MSACCESS.EXE loading "cold".
So, the problem is most likely in Windows and not Access.
I spent ages looking for the answers to this on various sites but eventually cobbled together my own fix, so hopefully this saves others some time.
This worked for me and reduced the load time from circa 4 minutes - even just opening a blank accdb fle - to seconds... So 4 mins if double-clicking an accdb. Once MS Access open and using File | Open it was fast.
I had two instances of MS Access both on Windows Servers that can see the Internet but goes through a corporate proxy etc.
After getting some hints by Googling this issue I suspected that the 4 mins or so was some sort of timeout trying to access a site or sites (MS Office apps do this) and that eventually when the proxy returned a timeout then Access started responding again. It was quick on the 2nd open because it didn't redo this request.
Based on this, I tried to divert certain sites to 127.0.0.1 and turn off all the Internet options in Trust Centre | Privacy etc. Nothing worked.
Finally, I got the solution. In Windows Defender firewall I created a new Application rule for the MSACCESS.EXE. This was an outbound rule that blocked all Internet traffic. After this the first double-click was fast again. I assume with traffic totally blocked, whatever request is going out to sites, is immediately stopped and returns a "no internet" to Access, which then carries out executing, rather than waiting for the 3-4min timeout.
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?).
On certain programs you can run them on a demo period for say 'ten tasks' or '5 hours' before you need to decide to purchase them to keep using them, but if you delete and uninstall the program then reinstall it, it knows that its been previously installed and wont let you run the demo again.
How does it do this ? When you download it does it send a identifiing number (ip ?) to the cdn to let it know youve downloaded it before, or when the program itself installed does it check to see traces of previous installation ?
Most "demo" software does this by a feature borrowed from malware: Incomplete deinstallation. A file or registry key belonging to the software is not removed on deinstallation. On reinstallation the software sees the remainder and can act on it.
Often-used hiding places for such a remainder were the system directory (before UAC arrived), but many register some class GUID - nobody I know of has a real overview of which classes in the registry are or are not genuine.
There are many ways this can be implemented.
The easiest way to implement (and also the easiest way to bypass)
On first run, create a registry (or text file) entry somewhere
Add 1 to the counter every time the task (or the app) is run
Do not include this file/registry in the installer app (so it will persist after uninstallation)
If at any time the count is too high, notify the user that the trial has expired.
Using image diff tools this method is pretty easy to identify and overcome.
The hardest method to overcome or bypass is to use a server. On the first run, generate a hash code based on the users computer name, drive serial number, etc, and post this to your server. The server then tracks this as a unique installation, and allows the app to run. Each time you run the app, you update the server. This way, the user cannot find the breadcrumbs and delete them, since they are on your server. The down side, is that this method will require an Internet connection.
There are probably much more sophisticated methods to achieve this result, but the above are both implementations I've run across.
My software drops breadcrumbs within the users system which is used to check for previous installations. This is a little harder to get around (assuming you don't know what you are looking for, or where) than an internet check against your IP. As you can always spoof your connection information, or just disconnect from the internet while installing.
I would like my computer to do specific tasks periodically or at a specific time.
Such as:
to wake up each 15 minutes, connect to the Internet, check e-mail, beep (if there is unread mail), then go standby again
to wake up at 8 am and play music
In the best case, it should be asleep and therefore, silent and going low-power.
It's no problem to make it connect or check the mail, but how to make it wake up ... ?
Do you happen to know the software to achieve this or windows API to use ?
I feel like there is one, but I failed to find it.
WakeUpOnStandBy (Windows)
CreateWaitableTimer
SetWaitableTimer
SetSuspendState to enter the suspended state.
CancelWaitableTimer
More info for example here.
Other alternatives require some more hardware support - like for example the Wake-On-Lan feature or IPMI.
Some computers have options like what you want in BIOS. I don't believe there's any way without BIOS support. Once your computer is asleep there's no programmatic way for it to wake up, since any such program is asleep...
An application is hanging occasionally, and I would like to see the dump at the time to figure it out. I had written an application that the user can run to automatically create a dump that I can look at. However I can't seem to get the users to remember to run it when it hangs, no matter what I try. They always end up closing the program, which invokes Windows Error Reporting.
WER will create dumps in the temp directory, but unfortunately they are deleted as soon as the dialog for sending the info to Microsoft or not is closed.
Becoming an ISV and getting this info from Microsoft's error reporting servers is one solution.. but not one that is realistic at the moment.
I can't imagine that I am the only one faced with this issue. The software is used concurrently by dozens upon dozens of staff, so reaching them all and getting them to run an application or not click close on that dialog until running some other application or etc has not been working out.
The app is running on Windows Server 2003. Too bad, since I know Server 2008 has some LocalDumps options that will let me retain them.
Any ideas for somehow keeping these dumps around so I can analyze them? The obstacle is the user, in the sense that I've accepted to their stubbornness and do not expect them to run any other application or do anything special.
Thanks for any advice!
You could opt for an automatic solution. I believe there're multiple options at your disposal for detecting if you're hung.
One would be the use of SendMessageTimeout (also pay attention to SMTO_ABORTIFHUNG as one of the fuFlags values) from a separate thread in your app. Once you have determined the main thread is not responding you can save a dump file wherever you want.
There's also a IsHungAppWindow() (user32.dll) available since w2k.