| Author |
Message |
|
Tony Hamilto
#1 / 16
|
 GPF in DAO2516.DLL??? Hello,
I have distributed a 16-bit VB4 application to many people, and
most are not having a problem installing and running it. Some,
however, are. At a point in the code where the database engine
is initialized (set MyWs = DBEngine.Workspaces(0)), they get the
following GPF:
... caused a general protection fault
in module DAO2516.DLL at 002d:00000044.
Registers:
...
Bytes at CS:EIP:
8e 46 fe 26 39 7f 04 74 e0 26 8b 07 26 8b 57 02
Stack dump:
2e3606c0 00064c44 00e4d478 001c386f 927d06c0 9074bff7 900082ad
528c82ad 8028c10a
b384bff7 00008155 927d0000 9000bff7 000082ad 00000000 96660000
I deleted the information under "Registers" because this part varies
from user to user. The rest is always the same. The problem has
occured under both Windows 95 and Windows 3.1. Thus far, I have
considered the following:
1. Maybe dao2516.dll isn't registered properly. So, I wrote a small
program to register it and gave it to the users with the problem.
It worked fine, but no change. Is it possible for a DLL to
be registered incorrectly, however? I was thinking that if it was
registered wrong once, it might not be corrected by simply trying
to register it again... how can you tell?
2. Perhaps there is a file that I am not distributing, but should be.
Through careful testing, I had previously determined the files
needed (working with "clean" systems). However, perhaps there's
something I'm missing - something that even these clean systems
didn't need, that most systems have anyway, but for some reason
is needed in some cases... ?
3. Something else in the system configuration. Are there incompatibility
issues with dao2516.dll and other loaded DLL's, memory
configurations, or anything else?
For reference, this is VB4.0, not 4.0a. I have checked the KnowledgeBase
and could not find anything. Something else interesting: I have noticed
that sometimes when an untrapped database error occurs, subsequent
database accesses will generate a similar error in dao2516.dll. In
this case, however, it is at the point of database initialization
that the problem is occuring...
Any help would be greatly appreciated...
Tony Hamilton
|
| Thu, 29 Apr 1999 03:00:00 GMT |
|
 |
|
Tony Hamilto
#2 / 16
|
GPF in DAO2516.DLL??? Quote:
> I wish I knew the answer, Sorry, but at least you are not alone. I get the
> exact same error. At first I thought it was a Win 3.1 problem, but now I
> get it myself in testing (Win 95). It seems to happen more when resources
> are heavily taxed, but with 32 mb ram and 170 mb swap, this really doesn't
> make sense. Are you using access databases? I get it on access and fox
> 2.6 files. Let's keep each other posted as we attempt to unlock the
> mystery. Good Luck, Phil
It turned out to be 2 things: 1. The client was running an older version of MSAJT200.DLL
2. My installation program wasn't overwriting the older version
of MSAJT200.DLL
I fixed 2, and the problem is solved.
Tony Hamilton
|
| Fri, 30 Apr 1999 03:00:00 GMT |
|
|
|
Phil Well
#3 / 16
|
GPF in DAO2516.DLL??? I wish I knew the answer, Sorry, but at least you are not alone. I get the
exact same error. At first I thought it was a Win 3.1 problem, but now I
get it myself in testing (Win 95). It seems to happen more when resources
are heavily taxed, but with 32 mb ram and 170 mb swap, this really doesn't
make sense. Are you using access databases? I get it on access and fox
2.6 files. Let's keep each other posted as we attempt to unlock the
mystery. Good Luck, Phil
Quote: > I have distributed a 16-bit VB4 application to many people, and > most are not having a problem installing and running it. Some, > however, are. At a point in the code where the database engine > is initialized (set MyWs = DBEngine.Workspaces(0)), they get the > following GPF: > ... caused a general protection fault
> in module DAO2516.DLL at 002d:00000044.
|
| Fri, 30 Apr 1999 03:00:00 GMT |
|
|
|
James00
#4 / 16
|
GPF in DAO2516.DLL???
Quote: > Hello, > I have distributed a 16-bit VB4 application to many people, and
> most are not having a problem installing and running it. Some,
> however, are. At a point in the code where the database engine
> is initialized (set MyWs = DBEngine.Workspaces(0)), they get the
> following GPF:
> ... caused a general protection fault
> in module DAO2516.DLL at 002d:00000044.
> Registers:
Unfortunately I am having a similar problem. It happens when running a CRW 5 report. My machine works fine but every machine I install the program on causes ... caused a general protection fault in module DAO2516.DLL at 002d:00000044. Let's keep each other informed I am using other methods trying to solve this problem.
|
| Sat, 01 May 1999 03:00:00 GMT |
|
|
|
Daryl Tayl
#5 / 16
|
GPF in DAO2516.DLL??? I have had the same error, ... and other DLL or OCX type errors. I
created a VB4.0 16 bit app and have distributed it to about 50
different PCs. The user base has the entire gamut from win95 to
win3.1 and some with programming languages installed, office 95, etc.
My installation will install the program and it works perfectly on
most of the PCs. But about 1 out of 8 will have a DLL or VBX, OCX type
problem. common errors are error 438, error 41037, and others.
My problems seem to occur most often when someone has VB or other VB
apps already installed on their machines. This problem must have an
answer, yet I can't seem to find one other than hours of guessing and
replacing system files. The users get tired of this long process and
start to think I am incompetent.(maybe I am)
I believe the problem lies herein:
MS has decided that c:\windows\system should house system files that
are shareable and later files are to be backward compatible(yeah
right)
All the damn install programs refuse to install a file in
windows\system that is older than the one existing, yet the newer
file may not be compatible with our app. THUS a problem.
I cannot figure out how to force VB4 install or installit express pro
to install these files over the others. And if I force this to happen
what other problems will I create for my users.
Question:
what is a program's read order for system files??
c:\windows
c:\windows\system
c:{program dir}
which is read first???? can i install all my files in my own
directory - windows just seems to ignore them when I do.
Please help solve this problem - I am very frustrated with VB!!!!!
Quote:
>Hello,
>I have distributed a 16-bit VB4 application to many people, and
>most are not having a problem installing and running it. Some,
>however, are. At a point in the code where the database engine
>is initialized (set MyWs = DBEngine.Workspaces(0)), they get the
>following GPF:
> ... caused a general protection fault
> in module DAO2516.DLL at 002d:00000044.
> Registers:
> ...
> Bytes at CS:EIP:
> 8e 46 fe 26 39 7f 04 74 e0 26 8b 07 26 8b 57 02
> Stack dump:
> 2e3606c0 00064c44 00e4d478 001c386f 927d06c0 9074bff7 900082ad
>528c82ad 8028c10a
> b384bff7 00008155 927d0000 9000bff7 000082ad 00000000 96660000
>I deleted the information under "Registers" because this part varies
>from user to user. The rest is always the same. The problem has
>occured under both Windows 95 and Windows 3.1. Thus far, I have
>considered the following:
>1. Maybe dao2516.dll isn't registered properly. So, I wrote a small
> program to register it and gave it to the users with the problem.
> It worked fine, but no change. Is it possible for a DLL to
> be registered incorrectly, however? I was thinking that if it was
> registered wrong once, it might not be corrected by simply trying
> to register it again... how can you tell?
>2. Perhaps there is a file that I am not distributing, but should be.
> Through careful testing, I had previously determined the files
> needed (working with "clean" systems). However, perhaps there's
> something I'm missing - something that even these clean systems
> didn't need, that most systems have anyway, but for some reason
> is needed in some cases... ?
>3. Something else in the system configuration. Are there incompatibility
> issues with dao2516.dll and other loaded DLL's, memory
> configurations, or anything else?
>For reference, this is VB4.0, not 4.0a. I have checked the KnowledgeBase
>and could not find anything. Something else interesting: I have noticed
>that sometimes when an untrapped database error occurs, subsequent
>database accesses will generate a similar error in dao2516.dll. In
>this case, however, it is at the point of database initialization
>that the problem is occuring...
>Any help would be greatly appreciated...
>Tony Hamilton
|
| Sun, 02 May 1999 03:00:00 GMT |
|
|
|
Phil Well
#6 / 16
|
GPF in DAO2516.DLL??? Good Deal!!! The version I am using is dated 1/12/96. Is there
something newer? Thanks, Phil
Quote:
> It turned out to be 2 things: > 1. The client was running an older version of MSAJT200.DLL
> 2. My installation program wasn't overwriting the older version
> of MSAJT200.DLL
|
| Sun, 02 May 1999 03:00:00 GMT |
|
|
|
Alykhan Vira
#7 / 16
|
GPF in DAO2516.DLL??? On Wed, 13 Nov 1996 13:57:57 -0500, Phil Wells
Quote:
>Good Deal!!! The version I am using is dated 1/12/96. Is there >something newer? Thanks, Phil
>> It turned out to be 2 things:
>> 1. The client was running an older version of MSAJT200.DLL
>> 2. My installation program wasn't overwriting the older version
>> of MSAJT200.DLL
I am using MSAJT200.DLL version 2.50.1606 that is causing me GPFs. Is there a newer version? If so how do I get it. It seems that this file is distributed in a LOT of products. (VB , Access etc..) I'm really glad you guys have narrowed this down. I have been having
grief for many weeks now. It is really frustrating demoing the
software to the client and having it crash with the error. I have
noticed that I takes a reboot (W95) to fix the problem until it
happens again.
Alykhan.
|
| Mon, 03 May 1999 03:00:00 GMT |
|
|
|
Bill McCart
#8 / 16
|
GPF in DAO2516.DLL??? Quote:
> On Wed, 13 Nov 1996 13:57:57 -0500, Phil Wells
> >Good Deal!!! The version I am using is dated 1/12/96. Is there
> >something newer? Thanks, Phil
> >> It turned out to be 2 things:
> >> 1. The client was running an older version of MSAJT200.DLL
> >> 2. My installation program wasn't overwriting the older version
> >> of MSAJT200.DLL
> I am using MSAJT200.DLL version 2.50.1606 that is causing me GPFs. Is
> there a newer version? If so how do I get it. It seems that this
> file is distributed in a LOT of products. (VB , Access etc..)
> I'm really glad you guys have narrowed this down. I have been having
> grief for many weeks now. It is really frustrating demoing the
> software to the client and having it crash with the error. I have
> noticed that I takes a reboot (W95) to fix the problem until it
> happens again.
> Alykhan.
OK I have no idea what is going on either. Here is what I know. Code that never causes a GPF in VB3 does have the random DAO2516.dll GPF when ran under VB4. MSAJT200.dll is the same version in both cases. I don't think it is releated to the MSAJT200.dll. My work around has been I stayed with VB3.
|
| Mon, 03 May 1999 03:00:00 GMT |
|
|
|
Tony Hamilto
#9 / 16
|
GPF in DAO2516.DLL??? Quote:
> I'm really glad you guys have narrowed this down. I have been having
> grief for many weeks now. It is really frustrating demoing the
> software to the client and having it crash with the error. I have
> noticed that I takes a reboot (W95) to fix the problem until it
> happens again.
I don't think we've found _your_ problem. Our problem was definitely related to having an older version. The correct version for us _is_ 2.50.1606. There are obviously other problems which must be causing GPF's in dao2516.dll. Sorry this doesn't help. Tony Hamilton
|
| Mon, 03 May 1999 03:00:00 GMT |
|
|
|
Greg Vinal
#10 / 16
|
GPF in DAO2516.DLL??? Quote:
> I have had the same error, ... and other DLL or OCX type errors....
I had the same error as well! In Win95 I installed vb4 (16bit) then vb4 (32bit) in the same directory
(as stated was OK in the installation help). I got GPF when using ODBC
to Oracle DB. It seemed to me that there was an uninitialised variable
in the DAO2516.DLL as my VB app worked the first time it was run , but
GPFed every time after, even after closing VB and restarting.
The GPF has disappeared (so far!) since I reinstalled Win95, vb4
(16bit), and vb4 (32bit -- this time in a different directory)
Greg Vinall
|
| Mon, 03 May 1999 03:00:00 GMT |
|
|
|
Rick Littl
#11 / 16
|
GPF in DAO2516.DLL??? Hello All,
I just wanted to throw my 2 cents in on the DA02516.dll GPF. The
following observations were made under Access 2.0, Access 7, and VB4
16-bit when accessing oracle databases via ODBC. These are the
situations that I have gotten DAO2516 GPFs.
The main way I get this error is when I have more than 1 ODBC connection
by the same or different apps to DBs. Ex. An open Access session with
an attached table in display mode, and a running VB client. This is
guarenteed to create a DAO2516 GPF. I have seen this time and again on
many networks and on many different clients (all W95, Win 3.x PCs
running against Oracle and Access DBs, using Intersolve ODBC).
I have also gotten the DAO2516 when ccMail is open and I have an open
ODBC process open. One note, this GPF does not happen instantly for
me. I can have 2 ODBC sessions open for a short period of time before
the error occurs. My theory is that the inactive ODBC session is trying
to refresh and collides with the active session.
On the bright side I have found that instead of rebooting W95. I can
just reload the dll using the dll manager that came with the Intersolve
ODBC drivers I use. A small VB program could be written to do the same
thing.
One final note... I have never gotten this particular GPF when I had
only the one ODBC source open.
Questions/comments?
-Rick
Quote:
> Hello,
> I have distributed a 16-bit VB4 application to many people, and
> most are not having a problem installing and running it. Some,
> however, are. At a point in the code where the database engine
> is initialized (set MyWs = DBEngine.Workspaces(0)), they get the
> following GPF:
> ... caused a general protection fault
> in module DAO2516.DLL at 002d:00000044.
> Registers:
> ...
> Bytes at CS:EIP:
> 8e 46 fe 26 39 7f 04 74 e0 26 8b 07 26 8b 57 02
> Stack dump:
> 2e3606c0 00064c44 00e4d478 001c386f 927d06c0 9074bff7 900082ad
> 528c82ad 8028c10a
> b384bff7 00008155 927d0000 9000bff7 000082ad 00000000 96660000
> I deleted the information under "Registers" because this part varies
> from user to user. The rest is always the same. The problem has
> occured under both Windows 95 and Windows 3.1. Thus far, I have
> considered the following:
> 1. Maybe dao2516.dll isn't registered properly. So, I wrote a small
> program to register it and gave it to the users with the problem.
> It worked fine, but no change. Is it possible for a DLL to
> be registered incorrectly, however? I was thinking that if it was
> registered wrong once, it might not be corrected by simply trying
> to register it again... how can you tell?
> 2. Perhaps there is a file that I am not distributing, but should be.
> Through careful testing, I had previously determined the files
> needed (working with "clean" systems). However, perhaps there's
> something I'm missing - something that even these clean systems
> didn't need, that most systems have anyway, but for some reason
> is needed in some cases... ?
> 3. Something else in the system configuration. Are there incompatibility
> issues with dao2516.dll and other loaded DLL's, memory
> configurations, or anything else?
> For reference, this is VB4.0, not 4.0a. I have checked the KnowledgeBase
> and could not find anything. Something else interesting: I have noticed
> that sometimes when an untrapped database error occurs, subsequent
> database accesses will generate a similar error in dao2516.dll. In
> this case, however, it is at the point of database initialization
> that the problem is occuring...
> Any help would be greatly appreciated...
> Tony Hamilton
|
| Tue, 04 May 1999 03:00:00 GMT |
|
|
|
Bill McCart
#12 / 16
|
GPF in DAO2516.DLL??? Quote:
> Hello All,
> I just wanted to throw my 2 cents in on the DA02516.dll GPF. The
> following observations were made under Access 2.0, Access 7, and VB4
> 16-bit when accessing oracle databases via ODBC. These are the
> situations that I have gotten DAO2516 GPFs.
> The main way I get this error is when I have more than 1 ODBC connection
> by the same or different apps to DBs. Ex. An open Access session with
> an attached table in display mode, and a running VB client. This is
> guarenteed to create a DAO2516 GPF. I have seen this time and again on
> many networks and on many different clients (all W95, Win 3.x PCs
> running against Oracle and Access DBs, using Intersolve ODBC).
> I have also gotten the DAO2516 when ccMail is open and I have an open
> ODBC process open. One note, this GPF does not happen instantly for
> me. I can have 2 ODBC sessions open for a short period of time before
> the error occurs. My theory is that the inactive ODBC session is trying
> to refresh and collides with the active session.
> On the bright side I have found that instead of rebooting W95. I can
> just reload the dll using the dll manager that came with the Intersolve
> ODBC drivers I use. A small VB program could be written to do the same
> thing.
> One final note... I have never gotten this particular GPF when I had
> only the one ODBC source open.
> Questions/comments?
> -Rick
> > Hello,
> > I have distributed a 16-bit VB4 application to many people, and
> > most are not having a problem installing and running it. Some,
> > however, are. At a point in the code where the database engine
> > is initialized (set MyWs = DBEngine.Workspaces(0)), they get the
> > following GPF:
> > ... caused a general protection fault
> > in module DAO2516.DLL at 002d:00000044.
> > Registers:
> > ...
> > Bytes at CS:EIP:
> > 8e 46 fe 26 39 7f 04 74 e0 26 8b 07 26 8b 57 02
> > Stack dump:
> > 2e3606c0 00064c44 00e4d478 001c386f 927d06c0 9074bff7 900082ad
> > 528c82ad 8028c10a
> > b384bff7 00008155 927d0000 9000bff7 000082ad 00000000 96660000
> > I deleted the information under "Registers" because this part varies
> > from user to user. The rest is always the same. The problem has
> > occured under both Windows 95 and Windows 3.1. Thus far, I have
> > considered the following:
> > 1. Maybe dao2516.dll isn't registered properly. So, I wrote a small
> > program to register it and gave it to the users with the problem.
> > It worked fine, but no change. Is it possible for a DLL to
> > be registered incorrectly, however? I was thinking that if it was
> > registered wrong once, it might not be corrected by simply trying
> > to register it again... how can you tell?
> > 2. Perhaps there is a file that I am not distributing, but should be.
> > Through careful testing, I had previously determined the files
> > needed (working with "clean" systems). However, perhaps there's
> > something I'm missing - something that even these clean systems
> > didn't need, that most systems have anyway, but for some reason
> > is needed in some cases... ?
> > 3. Something else in the system configuration. Are there incompatibility
> > issues with dao2516.dll and other loaded DLL's, memory
> > configurations, or anything else?
> > For reference, this is VB4.0, not 4.0a. I have checked the KnowledgeBase
> > and could not find anything. Something else interesting: I have noticed
> > that sometimes when an untrapped database error occurs, subsequent
> > database accesses will generate a similar error in dao2516.dll. In
> > this case, however, it is at the point of database initialization
> > that the problem is occuring...
> > Any help would be greatly appreciated...
> > Tony Hamilton
I have gotten this GPF while using 1 data control accessing an Access database. No transactions, ODBC or other speed tricks were used. This is also with VB4.0a. The same code does not produce an error in VB3. There is a GPF that can occur with VB3 if you don't refresh the data control in the form load event (q126991) this does not prevent the DAO2516.dll error though.
|
| Tue, 04 May 1999 03:00:00 GMT |
|
|
|
Jerry Jugovic
#13 / 16
|
GPF in DAO2516.DLL??? Quote:
> Hello,
> I have distributed a 16-bit VB4 application to many people, and
> most are not having a problem installing and running it. Some,
> however, are. At a point in the code where the database engine
> is initialized (set MyWs = DBEngine.Workspaces(0)), they get the
> following GPF:
> ... caused a general protection fault
> in module DAO2516.DLL at 002d:00000044.
> Registers:
> ...
> Bytes at CS:EIP:
> 8e 46 fe 26 39 7f 04 74 e0 26 8b 07 26 8b 57 02
> Stack dump:
> 2e3606c0 00064c44 00e4d478 001c386f 927d06c0 9074bff7 900082ad
> 528c82ad 8028c10a
> b384bff7 00008155 927d0000 9000bff7 000082ad 00000000 96660000
> I deleted the information under "Registers" because this part varies
> from user to user. The rest is always the same. The problem has
> occured under both Windows 95 and Windows 3.1. Thus far, I have
> considered the following:
> 1. Maybe dao2516.dll isn't registered properly. So, I wrote a small
> program to register it and gave it to the users with the problem.
> It worked fine, but no change. Is it possible for a DLL to
> be registered incorrectly, however? I was thinking that if it was
> registered wrong once, it might not be corrected by simply trying
> to register it again... how can you tell?
> 2. Perhaps there is a file that I am not distributing, but should be.
> Through careful testing, I had previously determined the files
> needed (working with "clean" systems). However, perhaps there's
> something I'm missing - something that even these clean systems
> didn't need, that most systems have anyway, but for some reason
> is needed in some cases... ?
> 3. Something else in the system configuration. Are there incompatibility
> issues with dao2516.dll and other loaded DLL's, memory
> configurations, or anything else?
> For reference, this is VB4.0, not 4.0a. I have checked the KnowledgeBase
> and could not find anything. Something else interesting: I have noticed
> that sometimes when an untrapped database error occurs, subsequent
> database accesses will generate a similar error in dao2516.dll. In
> this case, however, it is at the point of database initialization
> that the problem is occuring...
> Any help would be greatly appreciated...
> Tony Hamilton
Hi I also had these intermitent problems. Some of the problems
where fixed with the 4.0a version. By the date of the
file of 1/12/96 it sounds like you do have the 4.0a version.
Are you using any DBLists ? or DBCombo Boxes ?
Well just to let ya know I went to VB 3.0 never felt comfortable
with the problems of VB 4.0
|
| Tue, 04 May 1999 03:00:00 GMT |
|
|
|
Chris Kont
#14 / 16
|
GPF in DAO2516.DLL???
Quote: > I have had the same error, ... and other DLL or OCX type errors. I > --- SNIP ---
> Question:
> what is a program's read order for system files??
> c:\windows
> c:\windows\system
> c:{program dir}
> which is read first???? can i install all my files in my own
> directory - windows just seems to ignore them when I do.
Windows uses the following scheme when searching for DLL's, OCX's, VBX's, etc.: 1. Current directory (initially set to the working directory of your shortcut/icon but in some programs this changes, e.g. Open File Dialog boxes, etc.) 2. The Windows directory. 3. The Windows\System directory. 4. The directory containing the executable for the current task, where your EXE file is. 5. The directories listed in the PATH environment variable. 6. The list of directories mapped in a network. You can put the system files in your program's directory, HOWEVER, if
another program
is using a certain DLL (or OCX, etc.) when your program tries to access a
DLL with the
same name, your program will use the one already loaded in memory. The
reverse is also
true, so problems can arise.
|
| Fri, 07 May 1999 03:00:00 GMT |
|
|
|
Roland W. Schulz
#15 / 16
|
GPF in DAO2516.DLL??? Quote:
> ...
> I cannot figure out how to force VB4 install or installit express pro
> to install these files over the others. And if I force this to happen
> what other problems will I create for my users.
> Question:
> what is a program's read order for system files??
> c:\windows
> c:\windows\system
> c:{program dir}
> which is read first???? can i install all my files in my own
> directory - windows just seems to ignore them when I do.
> Please help solve this problem - I am very frustrated with VB!!!!!
We have the same problem in Dao2516 when using Crystal Reports in whatever version. For the crw version that comes with VB 4.0 16 Bit I got an update and bugfix from crystal support (www.crystalinc.com). Now I have some DLL's that won't install because they are older then the versions of my customers but this are the only libs that work!!! I think its another little Microsoft / Windows shit with a common system
directory. It is hard to get out of our difficulties because Win95
searches in Windows-dir first and only last in my programm-dir.
let me know if someone has solved this.
Another Problem:
Our Problem is to execute 16 Bit VB programms correctly under Windows NT
Ver. 3.51. We noticed that especially when calling a Crystal Reports
Report file in a window. After doing that, we can normally go further in
our programm and it seems so that we are able to end the task correctly.
When we then want to start the same 16 Bit application (or another 16
Bit app.) once more, we cannot do that. The Programm does not start
twice. (Any 32 Bit appl. starts normally).
When we then want to end Win NT 3.51 itself there is a message, that our
application does not respond to the quitting of NT. Then the only way to
end NT is to put off the computer.
We cannot see our application after ending in the Taskmanager so we
thought, everything is ok.
We do not have these problems under Win 3.1, 3.11, 95 or Win NT 4.0.
Only in win NT 3.51 with a 16 Bit application.
Has anybody had the same trouble or solved it at last?
We are so thankfull about some helpfull hints.
c/o Thomas Viohl
|
| Fri, 07 May 1999 03:00:00 GMT |
|
| |
Page 1 of 2
|
[ 16 post ] |
|
Go to page:
[1]
[2] |
|
