I'm encountering a GPF bug that I cannot replicate because it's intermittent, so I cannot create an example to make it happen on-demand. But I'm hoping someone else has been encountering this bug and can offer more clues that could help identify the fix.

I have 2 scripts accessing the same website via urlget. Both scripts use hashtables where each item added contains text up to 2kb in length.

One script access 1 url every half hour, updating a hash table that can reach up to 20mb or so, and hsaving it each half-hour right after accessing the url. Never seems to be a problem with that script.

The other script accesses a different url each half second or so, where each url is used to add another of those items to the hashtable, and it hsave's the hashtable at the end when finished, as well as every 400 items being added while in progress.

It's the hsave at one of the intervals of 400 that seems to be when the GPF happens. When the crash happens, there's almost always a mirc*.tm_ file whose timestamp matches when the crash happened, and the content is what would be from the 2nd script hsaving to disk. In case it matters, the hsaves are both using the -i switch.

For the latest crash, the disk write had what appears to be correctly written item=data lines, except for the very last disk write that contains unexpected content, so maybe the crash is due to writing data from someplace random that it shouldn't be.

The latest *.tm_ file contains 2385 valid item=string lines, but following the $crlf for the last completed line, the remaining bytes are the hex string:

0x43 0x05 0x20 0x0d 0x0a

In this case, the correct disk write would've begun with an itemname= beginning with '4'.

Since the item count wasn't a multiple of 400, this tells me that it didn't write the whole hashtable database. before crashing.

update: another crash had a different invalid string as the final line following the $crlf:

0x0a 0x2a 0x0d 0x0a

1502 valid item=string before the bad line, again not a multiple of 400

update: another crash. The final garbled line was the same 0x43 0x05 0x20 0x0d 0x0a as above. 1st time I remember the crash being the larger hashtable on the 30 minutes timer, after writing 3.7 of 18mb

edit: and what event reporter is saying
Faulting application name: mirc.exe, version: 7.69.0.0, time stamp: 0x62d559f7
Faulting module name: ntdll.dll, version: 6.1.7601.23391, time stamp: 0x56e9a630
Exception code: 0xc0000374
Fault offset: 0x000c3b03
Faulting process id: 0x26b0
Faulting application start time: 0x01d8a617020b3af1
Faulting application path: C:\mIRC\mirc.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll


Last edited by maroon; 03/08/22 04:11 AM.