Thread: Abnormal Program Termination when executed from C:/Program Files

Such atrocities you're airing there!

GAAAK! What kind of obfuscation do you call this!:

Code:

                open:
                if(o->Dialog->Execute())
                {
                        loadDLL(o->Dialog->FileName);
                }
                else
                {
                        goto open;
                }

Fixed version that does the same thing:

Code:

                while(!o->Dialog->Execute())
                {}
                loadDLL(o->Dialog->FileName);

Mind you, there's more levels of indirection there than I'm happy with too.

Catch all blocks that do nothing, not even logging - EEEK! You're really trying to make bugs hard to find huh!

You and the standard C++ library don't get along at all huh?

i know, i know


re: indirection - i got into a bit of a bad habit with that because BCB FORCES you to use pointers more than would otherwise be necessary. if you try to instantiate an object derived from a point their object library off the stack, it generates compile-time errors saying "VCL Style Classes must be instatntiated using operator new". it also commonly gripes about not being able to copy by value.

i will say though that their DynamicArray class is quite good, though i find vector's access methods far more convenient.

anyway, yes i would love a critique of the style and efficiency of the code, as it's probably the worst and most hastily written of anything i've done, but that's really not what's biting me right now.

there are more oddities going on:

if i change an unrelated part of the code, the location from which it will successfully execute changes.

yesterday i removed some system administration functions, part of which entailed enabling some menus that were enabled by default.

now, inexplicably, it will execute from C:\Program Files\AppDir or C:\AppDir and NOT the user's desktop, where I had worked previously. the failure still occurs if and only if the spectrometer is plugged in though. it managed to cough up an EAccess Violation message at me if executed from the user's desktop, but other attempts at resolving the problems would just give me abnormal termination.

also, re: writing to protected folders: the default account on these machines is the admin. we have no reason to restrict the user's permissions.

Originally Posted by m37h0d

there are more oddities going on:

if i change an unrelated part of the code, the location from which it will successfully execute changes.

yesterday i removed some system administration functions, part of which entailed enabling some menus that were enabled by default.

now, inexplicably, it will execute from C:\Program Files\AppDir or C:\AppDir and NOT the user's desktop, where I had worked previously. the failure still occurs if and only if the spectrometer is plugged in though. it managed to cough up an EAccess Violation message at me if executed from the user's desktop, but other attempts at resolving the problems would just give me abnormal termination.

Sounds like memory corruption (corrupt path?), I would start by logging what happens (differently) when the device is plugged in / not.

Originally Posted by m37h0d

also, re: writing to protected folders: the default account on these machines is the admin. we have no reason to restrict the user's permissions.

All my XPe partitions are write protected.

i got this to happen on my laptop today while i was in the lab.

i got a more illustrative error message out of it:

Access violation at address 7475420A in module 'MSCTF.dll'. Read of address FFFFFFFF

i'm not using MSCTF.dll directly. apparently it has to do with MS text service. i have no idea how or where it is used.

i also found several other odd things that would make the program either functional or not in addition to the odd things described earlier:

changing the executable name to >16 characters will cause it to crash.

changing the name of the enclosing folder would cause a crash (from one with spaces to one with no spaces, btw)

when i changed the IDE project name to >16 characters (so that the exe title would be >16 chars) it would run no problems when executed through the compiler, but launching the application directly from the exe file caused it to crash.

the problem occurs when i call reference(). i can get data from the spectrometer otherwise, but for some reason this fails.



plz halp!

Run your app
Run WinDbg
Use WinDbg to attach to your app (you're now debugging it)
Use your app to invoke the function in question
WinDbg will catch the exception, and you can start looking around to see what the problem is.

Assembly can be debugged, especially if you also have a way to get a map-file.

But if you get an "Privileged instruction" exception, it usually means that your code is jumping into non-code sections, which is caused by one of a few things:
1. Bad code generated by the compiler.
2. Writing garbage to code-memory (you shouldn't be able to do that in the first place).
3. Dynamically generated code that is not generated correctly (do you build code at runtime at all?)
4. Random garbage in function pointers (unintialized/overwritten with rubbish) [or in C++, you could overwrite the vtable of a class with rubbish to achieve the same thing, since the vtable is for all intents and purposes a set of function pointers].
5. Messing about with the return address so that the code returns to a random place in memory.

The last one is probably the most likely - overwriting the stack by one or two bytes can lead to very strange things indeed.

If you can debug in assembler mode, you should be able to see if the code looks like sane code, or if it's complete garbage (at least if you are a little bit used to reading assembler code).

--
Mats

3. Dynamically generated code that is not generated correctly (do you build code at runtime at all?)

not per se, but i do insert instances of functors into a container at runtime that determine how the app runs

That's not the type of "generate instrucitons at runtime" I was thinking of.

I would try to debug in assembler and see if you can get a stack-trace.

--
Mats

4. Random garbage in function pointers (unintialized/overwritten with rubbish) [or in C++, you could overwrite the vtable of a class with rubbish to achieve the same thing, since the vtable is for all intents and purposes a set of function pointers].

looks like it was this! unitinitialized function ptr. i guess the big question is how the hell did i get away with this before!?!?

it started crashing through my compiler when i moved the source files into My Documents! lo and behold as soon as i could set breakpoints and step thru the code it was easy as pie to track it down

woot woot!

Originally Posted by m37h0d

looks like it was this! unitinitialized function ptr. i guess the big question is how the hell did i get away with this before!?!?

Either you lost the initialization at some point, or you didn't use that particular function pointer.

It is always a good idea to fill structures that have function pointers with some value that makes all it's pointers invalid before you fill them in (e.g. memset using 0, 0xCC or 0xDD would work). If you use such a pointer in Windows or Linux (from a 32-bit application), it will absolutely crash then and there, and usually the EIP value will show that you tried to execute at this "unfilled" place. On the other hand, if you just grab a chunk of stack memory, it may well contain addresses that are valid memory locations that can be "executed" such as return addresses to previous function calls or data addresses (strings execute quite well in x86 - it's all sorts of weird jumps that you wouldn't normally see in sensible code, but it will (most likely) not crash from running through ASCII text)

--
Mats