 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Shane Stump
Guest
|
 Posted: Fri Jul 16, 2004 1:42 am Post subject: Exception Log Error?? |
 |
|
I am not sure where to put this message so I am putting it here!
I have written an application that I statically link for distribution
simplicity. It works fine under Windows NT, 2000, and XP. It blows up under
ALL the Micro$oft TOY operating systems (95/98/ME).
I finally rebuild a Windows 98 machine and installed CB 6. My program
compiles/links fine. It turns out it is blowing up in the StartupCode BEFORE
it even calls WinMain. The error is an EAccessViolation.
Could a third party component be hooking something through linkage?
Any ideas on how to debug this?
Any ideas would be appreciated before I just tell users my application is
NOT compatible with anything less than Windows NT.
Thanks,
Shane
|
|
| Back to top |
|
 |
Jean-Marie Babet
Guest
|
| Posted: Sat Jul 17, 2004 12:29 am Post subject: Re: Exception Log Error?? |
|
|
Hello Shane,
The startup code indeed invokes initialization code that could be yours,
from a third party or the RTL itself. For example, global objects linked
into your application are constructed (have their constructor executed)
before WinMain. #pragma startup routines are also invoked at that time. The
latter is often a good way to track down the issue. The startup code
dispatches initialization based on the code's priority. Therefore you can
write a piece of code that executes before global constructors or before
other 'pragma startup' routines. By varying the priority it could help
narrow down the whereabouts of the failure.
For initialization code that has the same priority [such as global
constructors, which use the same mechanism as '#pragma startup' routines
behind the scene], the order of dispatch depends on the order in which the
linker encounters them. So here it can help to reorder objects and libraries
when invoking the linker: you may find that this global object's constructor
ran through fine but we crashed before getting to the construction of that
global instance. In this case the culprit is probably an object between
(link-wise) these two.
If you're up for it there's the option of stepping through the startup
code's dispatch logic. It helps to have a startupcode with debug info.
You'll use the 'l' option (Lower case L: Do not execute startup code) along
with the 'dexename' option. Again, here you can tediously step through, or -
commando-style - add a #pragma startup routine that contains a 'DebugBreak'
or __emit__(0xcc): the debugger will take you up to that routine and then
you can step.
Good luck with the hunt. I have fond memories of startup code debugging.
Regards,
Bruneau.
|
|
| Back to top |
|
|
Shane Stump
Guest
|
| Posted: Sat Jul 17, 2004 3:25 am Post subject: Re: Exception Log Error?? |
|
|
Thanks for the information! I am going to attempt again but this time I have
installed Microsoft Virtual PC so I might not have quite as rough of a time
as I did yesterday trying to debug stuff!
Regards,
Shane
"Jean-Marie Babet" <bbabet (AT) borland (DOT) com> wrote
| Quote: | Hello Shane,
The startup code indeed invokes initialization code that could be yours,
from a third party or the RTL itself. For example, global objects linked
into your application are constructed (have their constructor executed)
before WinMain. #pragma startup routines are also invoked at that time.
The
latter is often a good way to track down the issue. The startup code
dispatches initialization based on the code's priority. Therefore you can
write a piece of code that executes before global constructors or before
other 'pragma startup' routines. By varying the priority it could help
narrow down the whereabouts of the failure.
For initialization code that has the same priority [such as global
constructors, which use the same mechanism as '#pragma startup' routines
behind the scene], the order of dispatch depends on the order in which the
linker encounters them. So here it can help to reorder objects and
libraries
when invoking the linker: you may find that this global object's
constructor
ran through fine but we crashed before getting to the construction of that
global instance. In this case the culprit is probably an object between
(link-wise) these two.
If you're up for it there's the option of stepping through the startup
code's dispatch logic. It helps to have a startupcode with debug info.
You'll use the 'l' option (Lower case L: Do not execute startup code)
along
with the 'dexename' option. Again, here you can tediously step through,
or -
commando-style - add a #pragma startup routine that contains a
'DebugBreak'
or __emit__(0xcc): the debugger will take you up to that routine and then
you can step.
Good luck with the hunt. I have fond memories of startup code debugging.
Regards,
Bruneau.
|
|
|
| Back to top |
|
|
Shane Stump
Guest
|
| Posted: Sat Jul 17, 2004 3:58 pm Post subject: Re: Exception Log Error?? |
|
|
Well, using your advice, I found the problem! TEurekaLog was causing the
problem - removing it and my program now works under Windows 98/ME!
Thanks for the help.
Regards,
Shane
"Jean-Marie Babet" <bbabet (AT) borland (DOT) com> wrote
| Quote: | Hello Shane,
The startup code indeed invokes initialization code that could be yours,
from a third party or the RTL itself. For example, global objects linked
into your application are constructed (have their constructor executed)
before WinMain. #pragma startup routines are also invoked at that time.
The
latter is often a good way to track down the issue. The startup code
dispatches initialization based on the code's priority. Therefore you can
write a piece of code that executes before global constructors or before
other 'pragma startup' routines. By varying the priority it could help
narrow down the whereabouts of the failure.
For initialization code that has the same priority [such as global
constructors, which use the same mechanism as '#pragma startup' routines
behind the scene], the order of dispatch depends on the order in which the
linker encounters them. So here it can help to reorder objects and
libraries
when invoking the linker: you may find that this global object's
constructor
ran through fine but we crashed before getting to the construction of that
global instance. In this case the culprit is probably an object between
(link-wise) these two.
If you're up for it there's the option of stepping through the startup
code's dispatch logic. It helps to have a startupcode with debug info.
You'll use the 'l' option (Lower case L: Do not execute startup code)
along
with the 'dexename' option. Again, here you can tediously step through,
or -
commando-style - add a #pragma startup routine that contains a
'DebugBreak'
or __emit__(0xcc): the debugger will take you up to that routine and then
you can step.
Good luck with the hunt. I have fond memories of startup code debugging.
Regards,
Bruneau.
|
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
