AU3_MouseClick(...) reboots my machine

[flat5]

I am working on a C++ program which uses the DLL to invoke AutoIt functionality. So far I got several functions to work just fine: Run(), WinWaitActive(), and several others.

However, when I try to use MouseClick(), my machine suddenly reboots in a very ugly manner, making horrible sounds come out of my hard drive.

I am an experienced linux developer but I know precious little about windows programming, so I'm really at a loss on how to debug this problem. I'm also a little hesitant to just start debugging in a cut and try manner as my hard drive goes through a verification and repair process both times I've run the program which invokes AU3_MouseClick.

Are there any known problems with AU3_MouseClick? I can copy/paste my code if that will help reproduce the problem, but I'm really not doing anything special with it: just a move and then a click at the same coordinates. I tried two different speed arguments: 10, and -1, before giving up in fear for my machine.

Thanks,

Bob

[flat5]

More information:

A program consisting of a single line (replacing the example code):

AU3_MouseClick("LEFT", 0, 0, 1, -1);

causes the crash (I guess the reboot is automatic on "BSOD").

More interestingly, I downloaded the v2 DLL, and a single LeftClick ALSO produces a crash! Any ideas?

I have a KVM switch. Is there any chance that is interacting badly here somehow?

Thanks,

Bob

Edited November 17, 2004 by flat5

[this-is-me]

Do this to find out what that bsod says...

Right-Click My Computer

Click Properties

Click on the Advanced Tab

Under Startup and Recovery, Click Settings

Un-Check Automatically Restart

Retry it. I have a feeling that an existing problem on your system is causing this to happen.

[flat5]

Do this to find out what that bsod says...

Right-Click My Computer

Click Properties

Click on the Advanced Tab

Under Startup and Recovery, Click Settings

Un-Check Automatically Restart

Retry it. I have a feeling that an existing problem on your system is causing this to happen.

<{POST_SNAPBACK}>

I tried that. It says nothing interesting (to me). It's just a bunch of standard "blah blah" about turning off caching or shadowing or trying a different video adapter. I'm pretty sure all of that is standard pure guess. Then there's something like "STOP 0x0000008" and then maybe a few more hex addresses.

I have never had a BSOD on this machine ever before this (not that that's proof of no pre-existing problems.)

I tried booting in safe mode, as well as not using the KVM switch. Same result both times.

I don't know what else to try other than that.

Bob

[Valik]

Post your sample code that demonstrates the problem, please.

Edit: Also, are you using Visual Studio? If yes, then attach an entire sample project that demonstrates the problem. If not, then just the code will suffice.

Edited November 17, 2004 by Valik

[flat5]

Post your sample code that demonstrates the problem, please.

Edit: Also, are you using Visual Studio? If yes, then attach an entire sample project that demonstrates the problem. If not, then just the code will suffice.

<{POST_SNAPBACK}>

zip file attached with Visual C++ project which demonstrates crash.

Code is simply:

#include <Windows.h>

#include "AutoIt3.h"

int APIENTRY WinMain(HINSTANCE hInstance,

HINSTANCE hPrevInstance,

LPSTR lpCmdLine,

int nCmdShow)

{

AU3_MouseClick("LEFT",100,100,1,-1);

return 0;

}

Bob

Edited May 20, 2006 by Jon

[flat5]

More information:

Raw mouse_event() calls also crash my machine. For the love of god, how do you debug stuff like this? I'm biting my tongue on a windows rant.

Bob

[Valik]

No crash for me. Neither in release mode nor in debug mode does my PC crash.

[SlimShady]

*hint* And no-one mentioned which OS they're using... *hint*

[this-is-me]

Somehow, I automatically knew he was running XP...

Please give us the name of the driver it says in the BSOD.

[flat5]

Somehow, I automatically knew he was running XP...

Please give us the name of the driver it says in the BSOD.

<{POST_SNAPBACK}>

Correct, XP Professional.

There is no driver named on the BSOD, just STOP and then a bunch of hex addresses.

I got so frustrated with this I decided it was time for an upgrade and a finger cross.

Bob

[this-is-me]

It may be a hardware problem, or just a driver. I suggest you go to the author's website for each hardware device in your system and get the latest drivers for it (sound card, video card, lan, motherboard chipset, etc). If you still have the problem after that, you definately have some serious hardware issues.

[flat5]

It may be a hardware problem, or just a driver. I suggest you go to the author's website for each hardware device in your system and get the latest drivers for it (sound card, video card, lan, motherboard chipset, etc). If you still have the problem after that, you definately have some serious hardware issues.

<{POST_SNAPBACK}>

XP Service Pack 2 did resolve the problem. I appreciate the help on such a vague, system-dependent complaint.

Bob

Edited November 19, 2004 by flat5

[drak]

there should also be memory dump files on your PC, these will tell you what is causing the problem, I have the MS tool to read these files if you like or you can download the program yourself

here are some details I got from MS on how to use the program & where to get it:

I will use one of the minidumps you've provided as an example. 

1)  Download and isntall the debugging tools for Windows into the c:\debuggers directory on the machine where you will be analyzing dump files (not the machine that actually crashed).  The package can be downloaded from:

http://www.microsoft.com/whdc/devtools/deb...installx86.mspx

2)  Once installed, run the WinDBG utility from the programs menu.

3)  Press CTRL+S (File | Symbol File Path), and enter "SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols" (without quotes) as the symbol path.  You will need to create a c:\websymbols directory (or you can call it something else if you wish) that will be used as a cache for the downloaded symbol files.  More info on the web symbol server is available here:

http://www.microsoft.com/whdc/devtools/deb...ng/symbols.mspx

4)  Press CTRL+D (File | Open Crash Dump) and select the dump file you wish to analyse.  This can be a minidump, a kernel dump, a full dump, or even a user-mode process dump.  The debugger (a.k.a. WinDBG) will start downloading symbols for all of the binaries it finds in the dump file.  Depending on the speed of your internet link, this may take seconds, minutes, or in extreme cases even hours.  When its done, you will be presented with a prompt at the bottom of the page, and the debugger is then ready to receive input.

5)  The most simplistic command is "!analyze - v" (note the spelling).  That kicks off the !analyze process in verbose mode, and the result is the debugger's guess about the nature of the problem that led to the crash.

kd> !analyze -v

*******************************************************************************

*                                                                            *

*                        Bugcheck Analysis                                    *

*                                                                            *

*******************************************************************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)

An attempt was made to access a pageable (or completely invalid) address at an

interrupt request level (IRQL) that is too high.  This is usually

caused by drivers using improper addresses.

If kernel debugger is available get stack backtrace.

Arguments:

Arg1: fee6c004, memory referenced

Arg2: 00000002, IRQL

Arg3: 00000000, value 0 = read operation, 1 = write operation

Arg4: b7614646, address which referenced memory

Debugging Details:

------------------

CURRENT_IRQL:  2

FAULTING_IP:

CVPNDRV+15646

b7614646 ??              ???

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0xD1

LAST_CONTROL_TRANSFER:  from b7614bf7 to b7614646

TRAP_FRAME:  b6ff84cc -- (.trap ffffffffb6ff84cc)

ErrCode = 00000000

eax=fee6c004 ebx=fee6bbc2 ecx=00000100 edx=fee6c004 esi=fee6c004 edi=fee6bbd6

eip=b7614646 esp=b6ff8540 ebp=00000091 iopl=0        nv up ei ng nz na pe cy

cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000            efl=00010283

CVPNDRV+0x15646:

b7614646 ??              ???

Resetting default scope

STACK_TEXT: 

WARNING: Stack unwind information not available. Following frames may be wrong.

b6ff853c b7614bf7 fee6c004 fee6bbae 8150c9a0 CVPNDRV+0x15646

00010283 00000000 00000000 00000000 00000000 CVPNDRV+0x15bf7

FOLLOWUP_IP:

CVPNDRV+15646

b7614646 ??              ???

...

MODULE_NAME:  CVPNDRV

IMAGE_NAME:  CVPNDRV.sys

...

=========================================================================

Please note that the !analyze command is not authoritative - it can only find rather simplistic problems, and it is sometimes way off the mark.  The good news is that the majority of crashes are indeed fairly simple.  That does not mean the underlying code problems are themselves easy to fix.

Lastly, this is all a huge oversimplification of an extremely complex topic.  To debug more complex issues requires architectural knowledge of the operating system as well as the hardware.  Unless one is familiar with stacks, deadlocks, semaphores, load addresses, and assembly language, it is very difficult to move beyond the !analyze command.  Once EAX, ECX, EDX, EBX, ESP, EBP, ESI and EDI have a certain sense of familiarity about them, it becomes truly interesting and rewarding to sift through "digital debris"!

If you're interested in debugging, I'd suggest the "Inside Windows 2000, 3rd Edition" book by David Solomon and Mark Russinovich (MS Press).