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