Send("#l") Windows XP <-> Windows 2003 R2

[Vermin]

Hi,

I have a small problem with the windows key seemingly 'stuck' on a windows 2003 R2.

The idea is to start up a (dos) program and type in some options.

In the ending, we lock the computer.

sleep(30000)
Run("D:\gsm\GLOBAL.EXE d:\Gsm\GL-IPL.DLV")
winWaitactive("Global System Manager")
sleep(5000)
send("xxx{enter}")
sleep(5000)
send("xxxx{enter}")
sleep(5000)
send("1{enter}")
sleep(5000)
send("3{enter}")
sleep(5000)
send("1{enter}")
sleep(5000)
send("1837{enter}")
sleep(5000)
send("#l")

It works like a charm and locks the computer nicely.

However, when we unlock the computer, the windows key seems 'stuck'.

Meaning if you press l again, it will lock your computer. d will go to desktop, etc.

I've tried a script with only

send("#l")

And then the same thing happens.

When excecuting the script on a windows XP computer however, it locks, and does not have the windows key 'stuck'.

The script was compiled on the XP (SP2) machine

Any ideas?

* Maybe try winup, but which one?

* Will compiling it under 2003 make a difference?

[PsaltyDS]

Hi,

I have a small problem with the windows key seemingly 'stuck' on a windows 2003 R2.

The idea is to start up a (dos) program and type in some options.

In the ending, we lock the computer.

It works like a charm and locks the computer nicely.

However, when we unlock the computer, the windows key seems 'stuck'.

Meaning if you press l again, it will lock your computer. d will go to desktop, etc.

I've tried a script with only

send("#l")

And then the same thing happens.

When excecuting the script on a windows XP computer however, it locks, and does not have the windows key 'stuck'.

The script was compiled on the XP (SP2) machine

Any ideas?

* Maybe try winup, but which one?

* Will compiling it under 2003 make a difference?

I tried your one-liner and did not get the symptoms. It just locks the console on both XP Pro SP2 and Server 2003 Standard Edition SP1, with no issues after unlocking.

I'm not sure what you mean by "windows 2003 R2".

This was compiled on the XP box with 3.2.6.0. What version of AutoIt are you trying this with?

[Bert]

R2 is his version of windows. Have you Service packed it?

[PsaltyDS]

R2 is his version of windows. Have you Service packed it?

I found it: Windows Server 2003 R2

More Microsoft weirdness in version naming. R2 seems to be a utilities update to SP1 which came out before SP2. Don't have it to test against though...

[Vermin]

Hi guys, thanks for the replies.

I've been testing plenty more.

I initially used an older version. But after an update to the 3.2.6.0 I still had the same problem.

Since then I've only used that version to compile the scripts. I've compiled the script on each server, as well as the working xp version.

The windows 2003 R2 (standard edition) is indeed short for release 2. As far as I can understand it's a 'new' release of windows 2003 somewhat like the windows 98 second edition.

I've tried this on servers with SP1 and SP2 of windows 2003, but they all have the same problem.

The initial servers I tried it on, were all virtual machines, but I've also tested it on physical machines. They too have the problem.

Some more testing on a 'normal' windows 2003 SP1 also had the same problem.

I've tried with a server outside the domain, so it wouldn't get the domain policy, but even that one had the problem.

Any ideas on what else I might need to test?

The only thing I can think of is that it's either a bug, or a setting that was already 'misplaced' on the virtual machine outside the domain.

Anyone else who can reproduce what I have (just with the locking instruction)??

Thanks in advance

[PsaltyDS]

Any ideas on what else I might need to test?

The only thing I can think of is that it's either a bug, or a setting that was already 'misplaced' on the virtual machine outside the domain.

Anyone else who can reproduce what I have (just with the locking instruction)??

My test, which worked fine, was on 2003 SP1 plus many security patches. I don't think it's an AutoIt bug.