Announcement

**Florent Heyworth** · 30 Jul 2000, 05:25 AM

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

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

**Patrick Harvey** · 30 Jul 2000, 05:43 AM

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

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

**Eric Pearson** · 30 Jul 2000, 06:17 AM

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).]

**Eric Pearson** · 30 Jul 2000, 06:32 AM

> 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>

**Florent Heyworth** · 30 Jul 2000, 06:35 AM

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).]

**Patrick Harvey** · 30 Jul 2000, 08:44 AM

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

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

**Florent Heyworth** · 30 Jul 2000, 09:08 AM

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

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

**Eric Pearson** · 30 Jul 2000, 09:30 AM

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>

**Patrick Harvey** · 30 Jul 2000, 10:10 AM

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!

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

**Patrick Harvey** · 30 Jul 2000, 10:28 AM

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..

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

**Florent Heyworth** · 30 Jul 2000, 10:57 AM

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.vi...UNME.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

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

**Patrick Harvey** · 30 Jul 2000, 11:33 AM

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

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

**Frank Kelley** · 30 Jul 2000, 01:11 PM

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

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

**Patrick Harvey** · 30 Jul 2000, 02:31 PM

Another good suggestion. Thanks

Patrick

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

**Patrick Harvey** · 31 Jul 2000, 12:00 PM

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

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

**Semen Matusovski** · 31 Jul 2000, 12:31 PM

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.

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

**Peter Manders** · 31 Jul 2000, 03:13 PM

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.

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

**Patrick Harvey** · 31 Jul 2000, 03:28 PM

OK...I'll try it. Thanks

Patrick

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

**Patrick Harvey** · 3 Aug 2000, 03:50 PM

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....

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

Announcement

access violation

access violation

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment