Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

[Solved?] Crash Trace


  • Please log in to reply
18 replies to this topic
stevenp
  • Members
  • 197 posts
  • Last active: Sep 23 2014 05:47 PM
  • Joined: 28 Aug 2006
it consist 60-70% from functions
by "script" term I meant all lines of code included in the main .ahk, regardless of whether the code is wrapped to a function or class.

I wasn't aware too about Reliability tool. Thanks!
so, here are some of the Events generated by AutoHotkey.exe:

Faulting application name: AutoHotkey.exe, version: 1.1.8.0, time stamp: 0x5001675f
Faulting module name: ntdll.dll, version: 6.1.7601.17725, time stamp: 0x4ec49b8f
Exception code: 0xc0000374
Fault offset: 0x000ce6c3
Faulting application path: C:\Program Files (x86)\AutoHotkey\AutoHotkey.exe
Faulting module path: C:\Windows\SysWOW64\ntdll.dll
Report Id: 3cc47836-e1a1-11e1-b543-002421ddf6d0

0xc0000374 ?

Faulting application name: AutoHotkey.exe, version: 1.1.8.0, time stamp: 0x5001675f
Faulting module name: gdiplus.DLL_unloaded, version: 0.0.0.0, time stamp: 0x4f9235ab
Exception code: 0xc0000005
Fault offset: 0x70ca795b
Faulting application path: C:\Program Files (x86)\AutoHotkey\AutoHotkey.exe
Faulting module path: gdiplus.DLL
Report Id: eca4d90a-e228-11e1-b543-002421ddf6d0

this one is gdip-related, nevertheless after converting goto-gosub to loop-if - it's not crashing now

there was no error with stack-overflow error code, but the error was obviously recursive-related
"Simplifying complexity is not simple"

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

it consist 60-70% from functions

Functions are no less "dangerous" than gosub.

but the error was obviously recursive-related

It is very likely that you are mistaken.

0xc0000374 ?

Google is your friend. In this case, your friend says your script has corrupted the heap. This can also cause exception 0xc0000005 (access violation). Often when memory is corrupt, changing seemingly unrelated things can change the result. Hypothetically, the error in your script may still exist, but by coincidence it is no longer crashing. These problems are generally very difficult to debug; you need to go over the script very carefully, especially parts that use DllCall and/or NumPut.

stevenp
  • Members
  • 197 posts
  • Last active: Sep 23 2014 05:47 PM
  • Joined: 28 Aug 2006

These problems are generally very difficult to debug

ohh very very
"Simplifying complexity is not simple"

stevenp
  • Members
  • 197 posts
  • Last active: Sep 23 2014 05:47 PM
  • Joined: 28 Aug 2006
You were right, as always, a crash happened again.
Opened Reliability Monitor, but it doesn't want to refresh (pressing Refresh button does nothing)
It shows "Last Updated: 13:00", but it's 14:35 here.
I've called my friend and he says that Reliability Monitor collects 24 hours of data before it displays any results
<!-- m -->http://www.vistax64.... ... reset.html<!-- m -->
So, I said to my friend, let's run Event Viewer, and here we are, no need to wait 24 hours, all the Errors are logged and available instantly.
There I've found the last ahk crash details:

Faulting application name: AutoHotkey.exe, version: 1.1.8.0, time stamp: 0x5001675f
Faulting module name: ntdll.dll, version: 6.1.7601.17725, time stamp: 0x4ec49b8f
Exception code: 0xc0000374
Fault offset: 0x000ce6c3
Faulting process id: 0x222c
Faulting application start time: 0x01cd79445b1bea7d
Faulting application path: C:\Program Files (x86)\AutoHotkey\AutoHotkey.exe
Faulting module path: C:\Windows\SysWOW64\ntdll.dll
Report Id: e7d6bfb0-e539-11e1-b0d1-002421ddf6d0

0xc0000374 again :(

My friend says

http://forums.iis.net/t/1150912.aspx
an event log is not of much use here. As I mentioned in my previous post the best bet here is a memory dump. Be forewarned that heap corruptions are quite challenging to figure out even with dumps as there are very few clues to go with.

The error code 0xc0000374 indicates a heap corruption - like Mukhtar said earlier, you will need to collect a crash dump and debug it to figure out what code is causing the heap corruption - also, you can use gflags/app-verifier to enable page-heap which will ease debugging of heap corruption. If you do not know how to enable page-heap/collect a crash dump/debug it, you should open a case with microsoft support and they can guide you through it.

That will be a long story
"Simplifying complexity is not simple"