do you know of an Addin for debugging compiled?

[Eduardo]

Sometimes I need to find errors that only occur compiled.

Several times I used 'VBSourceTrace', a program that adds code to all the
procedures.
But it's not user friendly and is too buggy. (BTW it's not an Add-in).

I wonder if there is an Add-in that I could use to add some code to all the
procedures, when the flow of the program enters the procedure and when it
exits it, so I can log the activity and see where the program crashed. Do
you know of any?

Thanks.

[GS]

I use a central error handling system and I tag procedures as
follows...

Const sSource$ = <procedurename>

..for subs, and...

Const sSource$ = <procedurename()>

..for functions. The error log will then be updated with this and the
error info (# and description) which could be standard VB info or
custom info at my discretion.

--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion

[Farnsworth]

"Eduardo" <m...@mm.com> wrote in message
news:klmv9j$7g9$1...@speranza.aioe.org...

See here if you have VC6:

http://www.tech-archive.net/Archive/VB/microsoft.public.vb.general.discussion/2008-05/msg01111.html

[ralph]

WinDbg.
http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx

After installing
Place Windbg.exe in the PATH
Command Prompt -> windbg -I
to install it as the JIT Debugger

Start your application.
Run it till it breaks, at which time WinDbg will open and show the
CallStack and point of failure.

Mystery solved!
Go fix it!

[You can also just attach the executable to Windbg in first place.
Or if even more postmortum information is needed open the dump (.dmp)
file with WinDbg.]

External components are mapped through VB6Debug.dll and ntdll. So the
final point of failure is usually not the trouble, but
something else up the line.

If you are interested in quickly identifying trouble in a compiled
application (especially native code), don't have VC++, nor that
familiar with CodeView THEN, IHMO WinDbg is the ONLY way to go.

Attach, launch, run, bang!, a couple of clicks, and there you are ...

[
When trying to resolve problems in 'release' (non-debug compiled) code
there are major problems with the common workarounds.

1) If you add additional code (instrumentation) there is always the
possibility of nudging things around enough to mask something that
would other-wise occur if the additional code wasn't there.

2) You can spend a lot of time instrumenting a lot of code to just
catch the ONE place a problem MIGHT occur. you end up writing a lot of
code that will likely NEVER be necessary. A major waste of time and
effort.

3) Adding 'debug information' to a compiled program can also mask
problems, because it shuts downs optimization and eliminates any
re-ordering or re-structuring that may be occurring in release code.
It can even cause an invocation of different 3rd party interfaces.
Optimization, re-arrangement, and different components ARE the primary
reason release code fails and debug code does not.

WinDbg is your friend.
]

-ralph

[Eduardo]

"ralph" <nt_con...@yahoo.com> escribi� en el mensaje
news:ee6un8hbg1f59rikf...@4ax.com...

Thanks Ralph, GS and Farnsworth.
I solved the problem this time in my usual way: using VBSourceTrace.
But I need to explore and study what Ralph suggested: WinDbg

VBSourceTrace didn't help in this case, the trace seemed "perfect", all the
procedures seemed to enter and exit until the program finished.
Because of some intuition I tried removing a Usercontrol that was inside
another Usercontrol, and the program didn't crash any more.
It seems that it was a reference to a control inside a class module that
didn't allow the class module to terminate. I changed the reference for an
uncounted, illegal reference to that control (a ComboBox), and the program
didn't crash any more.

[Deanna Earley]

On 30/04/2013 02:41, ralph wrote:
> On Mon, 29 Apr 2013 20:21:36 -0300, "Eduardo" <m...@mm.com> wrote:
>
>> Sometimes I need to find errors that only occur compiled.
>>
>> Several times I used 'VBSourceTrace', a program that adds code to all the
>> procedures.
>> But it's not user friendly and is too buggy. (BTW it's not an Add-in).
>>
>> I wonder if there is an Add-in that I could use to add some code to all the
>> procedures, when the flow of the program enters the procedure and when it
>> exits it, so I can log the activity and see where the program crashed. Do
>> you know of any?
>
> WinDbg.
> http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx
>
> After installing
> Place Windbg.exe in the PATH
> Command Prompt -> windbg -I
> to install it as the JIT Debugger
>
> Start your application.
> Run it till it breaks, at which time WinDbg will open and show the
> CallStack and point of failure.

That only applies if it's a win32 exception.
VB errors don't come into this and essentially use a dummy exception
(Float inexact result) that is handled at the bottom of the call stack,
where your useful stack trace has been lost.

You may have more luck adding a first chance exception handler in WinDbg
after attaching to the running process but I expect this will hit many
"safe" errors too.

--
Deanna Earley (dee.e...@icode.co.uk)
iCatcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be ignored. Please reply to the
group.)

[ralph]

A good addition.

I didn't go into this that much, considering a warning about
redirection through VBDebug and NtDll as enough to advise the
first-time user to look back on the stack. Time and experience, like
everything, will make it easier.

"VB Errors" should never (better make that seldom <g>) be an issue if
one always programs to avoid unhandled exceptions (or at least catch
the VB ones). IMHO, a manditory practice because as you noted VB
swallows most into its own error management scheme. However, even
these are decipherable with practice.

-ralph

[ralph]

On Tue, 30 Apr 2013 16:11:45 +0100, Deanna Earley
<dee.e...@icode.co.uk> wrote:

>On 30/04/2013 02:41, ralph wrote:
>> On Mon, 29 Apr 2013 20:21:36 -0300, "Eduardo" <m...@mm.com> wrote:
>>
>>> Sometimes I need to find errors that only occur compiled.
>>>
>>> Several times I used 'VBSourceTrace', a program that adds code to all the
>>> procedures.
>>> But it's not user friendly and is too buggy. (BTW it's not an Add-in).
>>>
>>> I wonder if there is an Add-in that I could use to add some code to all the
>>> procedures, when the flow of the program enters the procedure and when it
>>> exits it, so I can log the activity and see where the program crashed. Do
>>> you know of any?
>>
>> WinDbg.
>> http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx
>>
>> After installing
>> Place Windbg.exe in the PATH
>> Command Prompt -> windbg -I
>> to install it as the JIT Debugger
>>
>> Start your application.
>> Run it till it breaks, at which time WinDbg will open and show the
>> CallStack and point of failure.
>
>That only applies if it's a win32 exception.

Wasn't sure what you meant. The command line instruction?

To setup WinDbg JIT Debugger for all platforms run the reg file at
this site. [Note: There is no impact if VS.Net is not installed or if
running 32-bit.]
http://blogs.msdn.com/b/dotnet/archive/2009/10/15/automatically-capturing-a-dump-when-a-process-crashes.aspx

Also useful is the instructions for setting WinDbg to automatically
attach to selected programs. Handy time-saver while developing.

-ralph