Announcement

Collapse
No announcement yet.

access violation

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • access violation

    This isn't really a PowerBasic question, but I do use it all
    the time and really appreciate the expertise you guys have and
    I was hoping one of you might be able to help me out...

    I run a technical support dept and I am at my wits end trying to
    solve a problem with our software on a small number of NT 4 PCs
    and I was hoping one of your geniuses might be able to help with
    this. The program is written in Visual C++... Some parts of the
    program is 16-bit and some is 32-bit... At the point where
    one 16-bit program ends the following error message appears on
    a small number of NT 4 PCs.

    X has caused an access violation in file ddd.exe.

    The character X looks like two S characters placed over each other
    overlapping... One S is slightly above the other S in this displayed
    character. I can't find this character anywhere...

    The ddd is the name of the 16-bit executable that just completed
    itself. On PCs with this problem, any 16-bit executable that
    was just called ends with the above message. The program then
    continues.

    On one customer's PC, the problem occurs after they load MDAC_TYP.EXE
    version 2.5 (from another program). Yes, we use MDAC_TYP in our
    software (version 2.1), but on the one
    PC at our location we can load MDAC_TYP 2.5 with no problems. We
    tried having the customer load Service Pack 6.0a...no fix...

    Any ideas at all, anyone?

    Patrick

    ------------------

  • #2
    Patrick an access violation is such a vague error message (i.e it
    can be caused by so many things) that it's very difficult to offer
    any constructive advice on what to do.

    You mention that your product is a hybrid 16/32 bit program: which
    parts of the program are 16bit? Is it a 16 bit program using the
    16bit odbc.dll along with the 16 bit thunking layer odbc16gt.dll
    (used to talk to odbc32gt.dll)?

    If so then the problem still *might* have to do with the
    mdac version even if you can't reproduce it on your site.
    Have you tried doing a fresh install of NT 4.0 and then installing
    mdac 2.5 with your product?

    What Service Pack of NT 4.0 version does your program crash on?

    Do your clients have msvc or dr watson on site. If they have msvc
    you could try telling them to press cancel when the access violation
    occurs and then have them send you a screen shot of the debug output.

    Good luck

    Florent



    ------------------

    Comment


    • #3
      The part that generates the msg is 16-bit and does use ODBC to write to
      an Access 2-compatible database. The customer has NT 4 SP 4 and even
      upgraded to 6.0a with no change in the problem. On the one PC
      at our location, we already had SP 6.0a.

      Interestingly enough, the problem always started after third
      party software was installed. On the customer's PC, the problem
      started after loading some proprietary software that they wrote.
      This software also installs MDAC-TYP 2.5. At our location, the
      problem only occurred when the user installed lots of shareware
      after our software... He loaded so much software that day we
      couldn't determine which caused the problem.

      In the customer's case, uninstalling our software, uninstalling
      their proprietary software, and then reinstalling our software
      did NOT fix the problem. This makes me think that a shared file
      is to blame. What I can't figure out is why 500 of their branches
      loaded our software and their own with no problem and yet 5
      branches had this problem.

      Upgrading to Service Pack 6.0a did not solve the problem (they had 4.0
      previously)...

      Any other ideas...? The mysterious double-S character should be
      a big clue... I've never seen it before... The error says
      the overlapping double-S character has caused an Access Violation in
      our executable... weird... If you have any ideas, please let me know!

      Patrick

      ------------------

      Comment


      • #4
        The "overlapping double S" character sounds a lot like the character that corresponds to ASCII character 21 (NAK). The Windows Character Map applet doesn't display characters less than 32, so you don't usually see it, but if I use PB/CC to PRINT CHR$(21) I can get it to display.

        Hmmm... I also found your character in the Character Map applet, looking at MS Sans Serif. Check out character 167. Is that it?

        I have no idea why that character would appear in the Application Error message box, I'm just trying to supply clues...

        -- Eric


        ------------------
        Perfect Sync: Perfect Sync Development Tools
        Email: mailto:[email protected][email protected]</A>



        [This message has been edited by Eric Pearson (edited July 30, 2000).]
        "Not my circus, not my monkeys."

        Comment


        • #5
          > The ddd is the name of the 16-bit executable that
          > just completed itself. On PCs with this problem,
          > any 16-bit executable that was just called ends
          > with the above message. The program then continues.

          I don't understand that part. What continues? You said the program just ended.

          If you're not sure which program is crashing, here is something else to try... Generally speaking, when an Application Error message box is dismissed, one or more items will disappear from the NT Task Manager's "Processes" tab. If you could have a customer make a list of everything in the Processes list (or have them do Alt-PrintScreen to create a screen capture), then cause the crash, then look at the Processes list and see what's missing, it might tell you what program is crashing.

          -- Eric


          ------------------
          Perfect Sync: Perfect Sync Development Tools
          Email: mailto:[email protected][email protected]</A>

          "Not my circus, not my monkeys."

          Comment


          • #6
            I don't consider the overlapping double S to be significant: it's
            *probably* an address which can't be displayed properly (thunking?)
            because of heap corruption (a guess). [UPDATE: Eric posted
            while I was writing this]

            The only other thing I can think of for the double S is the SS
            (stack segment register) which might have been loaded with
            an invalid descriptor...

            When thunking and getting pointers back the thunking layer
            translates the outer pointer to a selector with a 64k limit.
            If the application needs access to more than 64k of the block
            it should change the base address. Attempting to access more
            than 64k would probably generate a GPF. If the pointer points
            to an array of pointers or some other structures then their
            address will not be translated by the thunking layer.

            How does the error occur? In other words you have traced the
            error back to some shared file which could be causing the problem
            due to the installation of another product. What files does the
            proprietary sotware your client uses install? Possible culprits
            might be the msvc* versions, etc...

            On the other hand maybe the fact that other programs *may* have
            installed conflicting shared files *may be* a coincidence:
            what data are the versions of your program dealing with? Could
            the error be traced back to an overflow (due to unsupported
            types or fluke data)?

            Does your software run unattended or does it need user interaction?

            Cheers

            Florent

            ------------------


            [This message has been edited by Florent Heyworth (edited July 30, 2000).]

            Comment


            • #7
              You all have been very helpful. I have my pb/cc installed at
              my work pc so I can't check the chr$(21)... pb/dll 6 returns
              square characters for most characters with codes less than 32...

              Anyway, the idea to check the NT processes seems like a good one
              so I will try that Monday. However, once I know what process(es)
              has failed, I'm not quite sure how that will translate into a
              solution...other than using something like QUICKVIEW plus to view
              the DLLs etc that it calls so I can delete them and then perhaps
              reinstall our product....

              In response to another post, the error occurs when one
              executable ends and the launch of another begins... both called
              by the same program... an automatic process, not a manual
              or user-caused one.

              Please excuse my ignorance of what the term MSVC is...Microsoft
              Visual C? What specifically should I check in this regard?
              I know we use Visual C++ 6.x to write our software...

              What's weird about the error is that on the PCs with this problem,
              several executables cause this error to occur...the only change
              in the message is that the double-S character says it has caused
              an access violation in whichever executable has just ended..

              In other words, the executable ends as it should (before the next
              automatically begins)...the error says it has occurred in the
              first executable as it is exiting itself...

              The company with the proprietary software won't tell us what
              files their proprietary software installs other than MDAC_TYP 2.5...
              Their software and our software work fine on all PCs except
              on a few... A person at that company's helpdesk said they
              could duplicate the prooblem on one of their PCs by installing
              MDAC_TYP 2.5, but we could not duplicate this installing it
              on NT 4 SP 4 or 6........... Even loading SP 6.0a on a PC
              with the problem the error still occurs...

              If I could simple obtain a list of files installed by their
              software it would all make more sense... On Monday, I will check
              to see what processes end and will post additional info...

              (If any of you have additional ideas, PLEASE let me know. Thanks for
              those of you who have already responded!

              Patrick

              ------------------

              Comment


              • #8
                A good bet would be downloading the Dependency Walker from http://www.dependencywalker.com/ - load your executable on
                a system where the GPF occurs and have the client send you a
                screen shot of the output: it will should you all files it's
                depending on including dll versions, etc. If some imports are
                not found, etc you'll be able to tell from depends.exe.

                It would also be very helpful if you could run Depends.exe on
                your client's proprietary software - this will show you what
                files it uses. You *should* be able to check the output to
                determine if you have file version conflicts, etc

                Cheers

                Florent

                ------------------

                Comment


                • #9
                  Patrick --

                  > I have my pb/cc installed at my
                  > work pc so I can't check the chr$(21)

                  If you don't see it right away, use the Window Menu's Properites dialog to change the console font type. On NT systems, the bitmap console font supports ASCII < 32 but the TrueType console font doesn't. Or vice versa... I forget.

                  Does the character look like this? &sect

                  > pb/dll 6 returns square characters for
                  > most characters with codes less than 32

                  To clarify, Windows controls how characters are displayed, not PB/DLL. If you attempt to display a character that the current font does not support, the rectangle (or a different "default" character that is specified by the font itself) is automatically displayed. All PB/DLL can do -- or any computer language for that matter -- is to tell Windows to display a character "by number", and Windows is responsible for drawing the "glyph" that corresponds to that number in the current font.

                  Another tool that you might find useful is MSINFO. It comes with Visual Studio and may be available from other sources (perhaps from microsoft.com?). It has the ability to show you all of the EXEs and DLLs that are currently in memory, along with their version numbers, creation dates, and the paths from which they were loaded. Windows 98 has a less sophisticated program called "System Information" that is part of the default 98 installation.

                  -- Eric


                  ------------------
                  Perfect Sync: Perfect Sync Development Tools
                  Email: mailto:[email protected][email protected]</A>

                  "Not my circus, not my monkeys."

                  Comment


                  • #10
                    Yes, the character you showed is the character that
                    appears in the error message.

                    I'll try the other advise you both mention monday.

                    THANK YOU!


                    ------------------

                    Comment


                    • #11
                      Unfortunately, the dependency walker program mentioned above, won't
                      track a 16-executable.... I tried a similar program the other day.
                      Also, it is not possible to launch our executable alone due to
                      the built in security it has...it receives certain command line
                      parameters that constantly change in order to run..based on the time
                      and other functions...I can't recreate these by hand in the time
                      needed...

                      I do know there are two DLL's being called by this executable
                      before it exits (along with others), which look like Visual C++
                      DLLs. I can't remember there names right now... Is there
                      anything you would suggest I try regarding them?

                      Thanks..

                      ------------------

                      Comment


                      • #12
                        Hmm

                        forgot about the fact that depends.exe can't read NE files. There
                        used to be a utility called EXEHDR.exe which used to come
                        with Microsoft's C compiler (MSVC 1, 2 +?) - unfortunately
                        this does not show you the different file versions although
                        you will get an import table and the expected ordinal if
                        you run it as:

                        EXEHDR /v path_to_file > details.txt

                        Not as comfortable or as rich in detail but might be worth a try.
                        Most people won't have an old copy of MSVC so you might have
                        to look on the web to see if you can find it.

                        I did a quick search in Google and it returned only 1? link: http://www.mirror.ac.uk/sites/ftp.viglen.co.uk/FILES/OS/DOS/ASEMBLER/D1-RUNME.ZIP[peek]

                        I actually downloaded the file (scanned it with the latest virus
                        scanners - and it came out clean although you'll want to run
                        a check yourself)

                        YMMV

                        Florent

                        ------------------

                        Comment


                        • #13
                          Thanks... I might have an old Visual C lying around
                          somewhere... I'll check. Thanks!

                          ------------------

                          Comment


                          • #14
                            If you're trying to track down exactly where the GPF occurs, you might want to consider getting a copy of Norton Utilities. Their Crashguard app intercepts such errors and tells you specifically in which .exe or .dll the problem ocurred (as well as allowing you to recover from most crashes without trashing the entire system).

                            Frank

                            ------------------

                            Comment


                            • #15
                              Another good suggestion. Thanks

                              Patrick

                              ------------------

                              Comment


                              • #16
                                The crash is occuring in one of two processes. In the first,
                                the files it calls are called:

                                MFC250
                                MFCD250
                                KERNEL
                                USER
                                WIN87EM
                                CTL3D
                                GDI

                                In the second, the process that disappears (but perhaps on purpose), the files called are:

                                KERNEL
                                GDI
                                USER
                                KEYBOARD
                                WIN87EM
                                ODBC
                                ODBCINST
                                COMMDLG
                                SHELL

                                Any ideas guys? What is WIN87EM?

                                Patrick


                                ------------------

                                Comment


                                • #17
                                  WIN87EM.DLL is emulator of 8087 (math coprocessor) commands and was designed for 16-bit apps.
                                  Windows by itself does not use it, but early releases of some apps, for example, Excel 2.0 uses.



                                  ------------------

                                  Comment


                                  • #18
                                    I remember something about a CTL3D version mixup. W95 version getting installed on NT by certain apps. I guess it should get replaced by installing an NT service pack but this should be easy to check.

                                    Peter.


                                    ------------------
                                    [email protected]

                                    Comment


                                    • #19
                                      OK...I'll try it. Thanks

                                      Patrick

                                      ------------------

                                      Comment


                                      • #20
                                        To those who were interested, we deleted all files installed by
                                        MDAC_TYP 2.5 and reinstalled the earlier version we use and all
                                        was fine with the world!

                                        Very weird....

                                        ------------------

                                        Comment

                                        Working...
                                        X