Sudden memory problem with one of my progs

[Keith Waters]

One of my PbWin programs has suddenly started giving the following when I exit (in Windows message box).

The instruction at “0x129b371b” referenced memory at “0x00000000”. The memory could not be “read”. Click on OK to terminate program

The current version (PbWin 8.04) and all previous versions (PbWin 8.03 – 8.00) all do the same. None of the versions ever gave this problem before. This morning I upgraded ZoneAlarm – coincidence?

[Cliff Nichols]

Probably not a koinky-dink....but I have to ask, what is your program? and what does it do?

[Keith Waters]

The program displays two panes side by side. In the left (an EDM32 edit control) turtle graphics commands can be entered. In the right (a graphics pane or a QHTM html control) a drawing of the shape traced by the turtle graphics commands is shown or the computed properties of the shape. Apart from that it has the usual menu bar, toolbar, status bar – all pretty standard.

All versions of the program, current and old, have never given this problem before. It only started today and I’ve done no work on the program today. I’ve rebooted several times and it’s still there.

[Theo Gottwald]

Try switching
#DEBUG ERROR ON
#TOOLS ON
and make a TRACE Instruction to find exactly the place where the error occurs.
The worst thing that can happen is, that under these changed circumstances the error does not happen .

But most often you can locate the point of filure this way.

[Michael Mattias]

when I exit ...[GPF] The memory could not be “read”...
...The current version (PbWin 8.04) and all previous versions

This almost certainly that means you have a programming error in your 'end of program' logic, an error which was masked by something else until you changed something on your system (e.g ZoneAlarm).

Since the pointer is NULL, #DEBUG ERROR ON is probably the best way to find it since that will generate an ERROR 9 on a null pointer. TRACE or ON ERROR or using the stepping debugger will give you an indication when error #9 is flagged.

This only applies if the null pointer was referenced in a PB instruction. If the error occurred in one of the system modules (complete error message not shown) by passing a NUL pointer, then ERROR 9 will NOT be triggered.

[Keith Waters]

Nope – I already have #DEBUG ERROR ON and I’ve just tried tracing - thanks for the advice. I TRACE from the point of receiving a %WM_CLOSE in the main window procedure. Can’t see anything untoward in the trace file and it runs all the way to exit from the main window proc. I’m still getting the same message box.

I might add that this program has been demonstrated and marketed and installed on several machines. To my knowledge, it’s never done this before. Just very lucky?

One of the modules, the QHTM perhaps, corrupted?

[Michael Mattias]

>To my knowledge, it’s never done this before. Just very lucky?


Once upon a time, the actress Mae West showed a friend of hers a diamond ring she had received as a gift.

"My Goodness!" exclaimed the friend when she saw it.

"Goodness," retorted Ms. West, "had nothing to do with it."

In your case you may substitute "luck" for "goodness" as luck has nothing to do with it.

First, show the name of the module in which the General Protection Fault occurred. That is going to tell you where to look. Since you are already using #DEBUG ERROR ON, it is not possible that the nul pointer causing the page fault is being accessed in the current code module, since #DEBUG ERROR ON skips the offending statement under those conditions.

So.. we need to find what function IS attempting to use a NUL pointer (x00000000) and the name of the module is a really good start on that.That module name is in the complete error message (along with the code location).

MCM

[Russ Srole]

Is it possible that you've released some memory, but have a thread or timer event that is still processing that data?

[Keith Waters]

But how do I get the name of the module? All I’m getting is a message box that pops up after I exit the program. The message box has “Myapp.exe – Application Error” in its caption. Its message reads “The instruction at “0x129b371b” referenced memory at “0x00000000”. The memory could not be “read”. Click on OK to terminate program”. Under that there is an “OK” button. That’s all there is on the message box – there is no mention of a “complete error message” or the name of a module.

[Cliff Nichols]

The instruction at “0x129b371b” referenced memory at “0x00000000”. The memory could not be “read”. Click on OK to terminate program

and where Russ said:

Is it possible that you've released some memory, but have a thread or timer event that is still processing that data?

ding ding ding....we have a winner!.....

Most of the time when I see that error (or similar instruction error), the answer is that the program is ending, the thread has been released, but the thread is not completed and therefore causes an error on exit.

I would get a copy of SysInternals "ProcessViewer" and use it to see if your program is using some other resource (even if you are not aware of it), and if not, then I would triple-check anything using a thread, not even releases its handle, but the thread has actually completed (or escapes due to closing your program)

A simple check would be a messagebox in your close to tell you the current ThreadCount. (If more than 1 then you still have threads running)

[Michael Mattias]

A simple check would be a messagebox in your close to tell you the current ThreadCount. (If more than 1 then you still have threads running)

FUNCTION pbMain ()

....
....
  ' =============================================
  ' WAIT FOR ALL ADDITIONAL THREADS OF EXECUTION TO  
  ' COMPLETE BEFORE ALLOWING PROGRAM TO END 
  ' =============================================
  hthread()   = array of open handles returned by THREAD CREATE* 
  WaitForMultipleObjects _
         nElementsInhThread() , _
         BYVAL VARPTR(FirstElement of hThread()) , _
         %TRUE, _           ' wait for ALL objects to be signalled
         %INFINITE         ' If it takes for-ev-er, I will wait for you...

END FUNCTION ' PBMain

* or by doing an enumeration at this point, ignoring this TOE.
I think I once posted a demo of how to do this in source code forum. Search a little.

[Michael Mattias]

But how do I get the name of the module? All I’m getting is a message box that pops up after I exit the program.

You have to click on the "view technical info" link to get that. It will give you a module name.

Event viewer (Control Panel/Administrative tools) retains this info, too, under "application events (error)" so you don't need to make it happen again just to find the module name.

MCM

[Keith Waters]

Findings as follows.

THREADCOUNT

Returns 1 just before end of WinMain
Returns 1 on receiving WM_CLOSE in main window proc.

MCM’s enumeration code (many thanks)

No child threads just before end of WinMain
No child threads on receiving WM_CLOSE in main window proc.

There is no "view technical info" link on the error message box that pops up.
I looked in Control Panel > Administrative tools > Event Viewer and there are no errors logged for today.

[Michael Mattias]

Every time I get a GPF I get a screen that offers to let me send the dump info to Microsoft. That's the screen with the "technical info" link. (Win XP/Pro all service packs and updates). And those GPFs always end up in event viewer, too.

If this is not enough info to get the module name you'll have to put in a call to "Level 2 Support" because you just went past my pay grade.

MCM

[Keith Waters]

Every time I get a GPF I get a screen that offers to let me send the dump info to Microsoft.

Yes – I know what you mean but I’m not getting that. I’m getting the message box that I described earlier.

[Cliff Nichols]

in that case I would grab SysInternals Processviewer and check to see if any processes are being loaded that you are unaware of.

[Michael Mattias]

check to see if any processes are being loaded that you are unaware of.

The problem dear Brutus,
Is not in our stars,
It is in our selves.

-- Willie --

[Keith Waters]

Ok, I’m now trying SysInternals Process Explorer.

With Process Explorer running, I run my application and the process “MyApp.exe” shows in the Process Explorer top pane (processes tree view). I right click and get Properties > Threads. There is just one thread listed, “MyApp.exe+0x4ac04”. This, I think, is as it should be.

Then I exit the application and the previously described message box pops up. The “MyApp.exe” process is still showing in the Process Explorer top pane so I again look at Properties > Threads (this time there is quite a pause before properties show). Now I see two entries, “!CreateThread+0x2e” and “ntdll.dll!RtlConvertUiListToApiList+0x276”.

I haven’t the faintest what this means. Googling “RtlConvertUiListToApiList” found this http://www.thescripts.com/forum/thread387063.html - something about FolderBrowserDialog and NET 1.1 SP1.

Keith

[Keith Waters]

Also, I see there are a lot of web links offering ntdll.dll repair or download.

I’ve just scanned my Windows directory with AVG but nothing corrupted was found.

[Roy Cline]

I suggest google

"The instruction at referenced memory at. "

Lots of references for this problem.