AutoIt passes invalid handle to CloseHandle during process shutdown

[jonathan.boeing@…]

Autoit crashes frequently when run on the checked build of Windows. The crash occurs when the process is shutting down. Investigation showed that the crash is due to an unhandled exception caused by passing an invalid handle to CloseHandle().

The MSDN docs for CloseHandle() state that it can raise an exception if an invalid handle is passed in.

Investigation showed that AutoIt appears to be passing an uninitialized value to CloseHandle(). If the value happens to be zero, the process doesn't crash. If the value is non-zero, the process crashes.

The exception was also reproduced on the free build of Windows when attaching a debugger to the process.

How to reproduce:

1. Run AutoIt either on the checked build of Windows or with a debugger attached
2. Run it from a command prompt without specifying a script (a script can be specified, but it is unnecessary to reproduce the exception).
3. Hit 'cancel' on the file dialog when it opens

The exception seems to be dependent on the process environment. Running the executable from different directories or with different command lines can make it either occur or not occur.

This was seen with both version 3.3.8.0 and 3.3.9.1

[Valik]

If you have determined directory paths or command line arguments that can cause the issue to occur then why aren't you mentioning those? I have better things to do than go on a wild goose chase hunting for some exception that may or may not trigger.

Remember, bugs need to be easily reproduceable. All you've given so far is a bunch of useless information about what happens during the crash but no useful information about how to reliably trigger the crash ourselves.

You didn't even provide an OS version, processor architecture and AutoIt platform to test on.

[anonymous]

OS: Windows 7 SP1
Arch: x64
AutoIt platform: (Not exactly sure what that means...) both AutoIt.exe and AutoIt_x64.exe

Sorry, I didn't have a 100% reliable repro method, but I think I do now. It appears to be dependent on the environment variables.

Working directory: "c:\bin"
Command line: "AutoIt3_x64.exe" (no additional parameters)

1. Start with the default set of env. variables in the command prompt
2. Run "AutoIt3_x64.exe", attach the debugger, and click "Cancel" in the file dialog
3. If the exception doesn't occur, run "set A=A" in the command prompt
4. Repeat step 2
5. If the exception doesn't occur, run "set A=AA" in the command prompt
6. Repeat step 2

I was able to make it alternate between causing the exception or not causing it with each additional character in the value of "A" (i.e. it occurred with A=A, didn't with A=AA, did with A=AAA).

I attached my default set of environment variables. I can also provide a process dump (33MB compressed) if desired.

[anonymous]

Default values of environment variables

[Valik]

Oh shit, that actually did give me an access violation.

[Valik]

I love Microsoft. I wrote very extensive code to ensure an access violation like this could never occur. There are tests everywhere to ensure the handles this code uses are valid. So what happens? Windows gives me a valid handle. It passes that check. However, a call to DuplicateHandle() fails with ERROR_INVALID_HANDLE even though I'm passing in a valid handle. I never dreamed that DuplicateHandle() would fail to duplicate a valid handle in-process so I didn't write error checking in one piece of code. I also didn't properly initialize a handle to NULL because, once again, that code is only executed when a valid handle is present.

Stupid. It's not even a single line fix, it's literally just m_hHandle(NULL), inserted into the initializer list. Then there's 8 lines of comments to explain why it's necessary in the first place.

In short, I've just spent time documenting yet another Windows bug in the AutoIt source code. Woo.

[Valik]

Fixed by revision [6843] in version: 3.3.9.2