Jump to content
Sign in to follow this  
stdoubt

When does XP finish loading?

Recommended Posts

stdoubt

Hi,

I have an autoit3 script that performs daily system healthchecks and reports on a bunch of services that I support. It runs on a remote desktop that and I have one of my support teams execute it before get into the office, so I know what I'll have to deal with for that day.

The script, while a bit messy, works perfectly well except that if the Windows desktop is still loading, the processes that the scripts start up don't behave very predicably, and more often than not, the healthcheck incorrectly reports failures as a result. While I could probably put some more logic in to allow the script to manage these situations, I figure the best this to do would just be to wait until the desktop is completely loaded.

So, the question is, how can I tell, automatically, that the desktop has completedly loaded?

Thanks,

STDOUbT

Share this post


Link to post
Share on other sites
bo8ster

Can you provide more info? What processes are you talking about?

Edited by bo8ster

Post your code because code says more then your words can. SciTe Debug mode - it's magic: #AutoIt3Wrapper_run_debug_mode=Y. Use Opt("MustDeclareVars", 1)[topic="84960"]Brett F's Learning To Script with AutoIt V3[/topic][topic="21048"]Valuater's AutoIt 1-2-3, Class... is now in Session[/topic]Contribution: [topic="87994"]Get SVN Rev Number[/topic], [topic="93527"]Control Handle under mouse[/topic], [topic="91966"]A Presentation using AutoIt[/topic], [topic="112756"]Log ConsoleWrite output in Scite[/topic]

Share this post


Link to post
Share on other sites
Genos

Could you just put the file in the startup folder and let windows execute it automatically when they login?

Share this post


Link to post
Share on other sites
GEOSoft

There really is no way to be accurate when checking it with time since that will vary by the system speed, software load at startup & etc. Probably best to first time all the systems and then determine from that when it's safe to start your app. I have one system here that takes all of 3 minutes to load XP so I would time the program to start after 4 minutes.

I don't remember for sure but I seem to recall that Apps in the UserStartup folder are the last to be processed so that may be another approach.


George

Question about decompiling code? Read the decompiling FAQ and don't bother posting the question in the forums.

Be sure to read and follow the forum rules. -AKA the AutoIt Reading and Comprehension Skills test.***

The PCRE (Regular Expression) ToolKit for AutoIT - (Updated Oct 20, 2011 ver:3.0.1.13) - Please update your current version before filing any bug reports. The installer now includes both 32 and 64 bit versions. No change in version number.

Visit my Blog .. currently not active but it will soon be resplendent with news and views. Also please remove any links you may have to my website. it is soon to be closed and replaced with something else.

"Old age and treachery will always overcome youth and skill!"

Share this post


Link to post
Share on other sites
storme

G'day stdoubt

you could try the method that athiwatc uses in his startup delay script http://www.autoitscript.com/forum/index.php?showtopic=93319.

If I remember correctly he waits till all the lowest priority programs are using less then 20% of the CPU.

This should at least give you an idea of when the computer is idle and by inference all the "start up activities have been done.

BTW wouldn't mind seeing your "health checks" messy or not >_< I'm always interested in what others think is important so I don't miss things.

Good Luck and hope that can help.

Share this post


Link to post
Share on other sites
stdoubt

Thanks for the replies...

The tests are all fairly simple - I have a bunch of random desktop applications that are all busines critical and need urgent escallation if anything is a miss. All my testing does is log in as a test account to each app (I had a lot of fun wokring out some method to encrypt passwords, etc so that I can could store the source somewhere unrestricted), run a few basic commands, take a screenshot of the results and past them to a report document for review at the end.

Some of them are a bit cleverer - in that if there is some recongnisible action that states that all is working ok, I'll just look out for the trigger and report "Status: Good" or "Status: Bad" in the report.

The reasons I need to know that the remote system has compeltely loaded is so that my desktop team who run the script in the morning/evening - who are not experts on my systems, and frankly don't have the time to wait for a dodgy script - can reliably start the process without thinking about it. If there is some junk still running in the background (such as overnight security scripts) it can cause unpredictable effects on the applications.

I don't want to just wait for a pre-determined amount of time, as it might take as much as 20 mins on some days to start up - sucks I know, but my desktop admins are paranoid in this place! - equally it might only take 5 mins. I also don't want to have to wait if the system has been running for ages...

I like storme's idea - I'll give that a shot and let oyu know how I get on.

STDOUbT

Share this post


Link to post
Share on other sites
WolfWorld

Thanks for the replies...

The tests are all fairly simple - I have a bunch of random desktop applications that are all busines critical and need urgent escallation if anything is a miss. All my testing does is log in as a test account to each app (I had a lot of fun wokring out some method to encrypt passwords, etc so that I can could store the source somewhere unrestricted), run a few basic commands, take a screenshot of the results and past them to a report document for review at the end.

Some of them are a bit cleverer - in that if there is some recongnisible action that states that all is working ok, I'll just look out for the trigger and report "Status: Good" or "Status: Bad" in the report.

The reasons I need to know that the remote system has compeltely loaded is so that my desktop team who run the script in the morning/evening - who are not experts on my systems, and frankly don't have the time to wait for a dodgy script - can reliably start the process without thinking about it. If there is some junk still running in the background (such as overnight security scripts) it can cause unpredictable effects on the applications.

I don't want to just wait for a pre-determined amount of time, as it might take as much as 20 mins on some days to start up - sucks I know, but my desktop admins are paranoid in this place! - equally it might only take 5 mins. I also don't want to have to wait if the system has been running for ages...

I like storme's idea - I'll give that a shot and let oyu know how I get on.

STDOUbT

Use my script, it's not 100% but it will work because the CPU load will get lower when the explorer is finish loading.

Share this post


Link to post
Share on other sites
JohnOne

I hate to geg in on a topic that is way beyond my knowledge, but Im going to make a blind suggestion anyway.

Is there a way to monitor the system idle process and run your script only when it is > 90% for 2 minutes or something ?


AutoIt Absolute Beginners    Require a serial    Pause Script    Video Tutorials by Morthawt   ipify 

Monkey's are, like, natures humans.

Share this post


Link to post
Share on other sites
WolfWorld

I hate to geg in on a topic that is way beyond my knowledge, but Im going to make a blind suggestion anyway.

Is there a way to monitor the system idle process and run your script only when it is > 90% for 2 minutes or something ?

That is what my script does. Look!~

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.