Abnormal Program Termination when executed from C:\Program Files\...

This is a discussion on Abnormal Program Termination when executed from C:\Program Files\... within the Windows Programming forums, part of the Platform Specific Boards category; 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); } ...

  1. #31
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,308
    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?
    Last edited by iMalc; 09-19-2008 at 03:36 AM.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  2. #32
    3735928559
    Join Date
    Mar 2008
    Location
    RTP
    Posts
    839
    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.
    Last edited by m37h0d; 09-19-2008 at 10:14 AM.

  3. #33
    train spotter
    Join Date
    Aug 2001
    Location
    near a computer
    Posts
    3,859
    Quote Originally Posted by m37h0d View Post
    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.

    Quote Originally Posted by m37h0d View Post
    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.
    "Man alone suffers so excruciatingly in the world that he was compelled to invent laughter."
    Friedrich Nietzsche

    "I spent a lot of my money on booze, birds and fast cars......the rest I squandered."
    George Best

    "If you are going through hell....keep going."
    Winston Churchill

  4. #34
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,598
    Which also means I am not welcome to work at Microsoft. Its listed as one of their basic requirements.
    No it's not. Have a friend that knows nothing of MFC and works at MS on the kernel team.
    And your statement is a bit wide-reaching since not everyone agrees that MFC or other so called 'useless' libraries are 'useless.'


    You only need to post the source code that is related the error you are receiving. I sure do not feel like pouring over tons of source code to 'find' your error. Unless of course you would like to pay me to do so?

    If you are relying on relative paths and are not sure if you have the right one I find that writing a test output file to the same relative path and then doing a search for it will save you a lot of pain. If the test output file is not in the right place then your relative path is incorrect.

  5. #35
    3735928559
    Join Date
    Mar 2008
    Location
    RTP
    Posts
    839
    well thanks for the feedback everyone, but i don't think this is anything i can do anything about.

    this is all code that has been reused for this project, its been used before with no such instability issues, but apparently this particular hardware set does not like my spectrometer's USB driver.

    i mean, this is really, really odd. one thing i noticed is that the exe title cannot be identical to the enclosing folder. i kid you not. changing the name of the exe would make it launch just fine! i could change it back and it would start crashing again. that, at least, was repeatable!

    i may be a sophomoric programmer, but i definitely know enough to debug repeatable errors. anyway, i guess there was nothing anyone here could do afterall. i figured it was something that was wholly my fault, but at this point i'm writing this off , as i have had total success on several other systems that i've tested it out on. thanks anyway everyone.

  6. #36
    3735928559
    Join Date
    Mar 2008
    Location
    RTP
    Posts
    839
    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!
    Last edited by m37h0d; 09-25-2008 at 02:03 PM.

  7. #37
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,764
    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.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  8. #38
    3735928559
    Join Date
    Mar 2008
    Location
    RTP
    Posts
    839
    when i tried that it complained about not having some standard charset and wouldn't initialize. i suppose in light of the new error message i got, that would be consistent with a problem with msctf

    will try again and post more detailed results

  9. #39
    3735928559
    Join Date
    Mar 2008
    Location
    RTP
    Posts
    839
    windbg can't successfully open the app, even when i can launch it successfully through windows.

    BCB uses OMF format, and the documentation says windbg can only evaluate symbols with files having COFF format, so i think all i'm going to get out of it is assembly that i don't know how to read.

    i can attach the app to BCB tho, but again, all i get there is assembly.

    i installed SP3 last night and now the error window reads "privileged instruction"

    i'm not writing anywhere, the logging function i had built in has been commented out.

  10. #40
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  11. #41
    3735928559
    Join Date
    Mar 2008
    Location
    RTP
    Posts
    839
    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
    Last edited by m37h0d; 09-25-2008 at 08:17 PM.

  12. #42
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  13. #43
    3735928559
    Join Date
    Mar 2008
    Location
    RTP
    Posts
    839
    yeah i didn't think so. what i'm doing is not nearly as clever.

  14. #44
    3735928559
    Join Date
    Mar 2008
    Location
    RTP
    Posts
    839
    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!
    Last edited by m37h0d; 09-25-2008 at 02:57 PM.

  15. #45
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by m37h0d View Post
    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
    Last edited by matsp; 09-25-2008 at 07:50 PM.
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

Page 3 of 4 FirstFirst 1234 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. List all system and program files
    By tnbui in forum Windows Programming
    Replies: 7
    Last Post: 07-10-2009, 03:43 AM
  2. Replies: 5
    Last Post: 02-11-2008, 01:36 AM
  3. We Got _DEBUG Errors
    By Tonto in forum Windows Programming
    Replies: 5
    Last Post: 12-22-2006, 05:45 PM
  4. Abnormal program termination
    By Kayoss in forum C++ Programming
    Replies: 3
    Last Post: 05-16-2006, 04:29 PM
  5. abnormal program termination
    By ProLin in forum C++ Programming
    Replies: 2
    Last Post: 01-20-2002, 09:56 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21