Prev: vb6 form in an Excel application
Next: Problem with a Registry program from Karen Kenworthy
From: Nobody on 9 Apr 2010 11:34
"ralph" <nt_consulting64(a)yahoo.net> wrote in message
news:4m0tr59bl9nr74snhlonu7ifld1glqm4rs(a)4ax.com...
> Meukal has explained the 'page faults'.
>
> There are ways to instrument a program to profile total memory usage
> but as you have discovered it tends to lead you down a interesting
> path (to a geek) but doesn't really provide much information to
> resolve your problem.
>
> My suggestion is for you to forget any assumptions and fire up WinDbg.
> (http://www.microsoft.com/whdc/devtools/debugging/default.mspx)
>
> Get an XP box, Setup WinDbg as the JIT Debugger. Find the point of
> failure and then back-track to the problem.

Ralph suggestion would find the exact line that caused the GPF. You need to
recompile your VB6 app with debug info, then use WinDbg. Once the GPF
happens, look up in the stack in the list of callers to the point in the
source code that caused the GPF. The crash itself would happen in an OS DLL
like ntdll.dll or kernel32.dll. You need to look up in the stack to see the
calling VB routine. This could be a CopyMemory line or whatever caused the
crash.

I have not used WinDbg, but the same thing can be done with VC. Once you run
your VB app, go to VC, and use Tools or Build menu and look for "Attach to
process", and once the software crashes, try to find the stack, and double
click what looks like a VB routine name that you are using.



From: Boris Pauljev on 10 Apr 2010 11:52
I have never experienced any paging errors, my crashes were ALWAYS
caused by 3rd party controls.

First  |  Prev  | 
Pages: 1 2
Prev: vb6 form in an Excel application
Next: Problem with a Registry program from Karen Kenworthy