VBA, Acc 97 SP1 crash at 0x0400a0af

Acc 97 SP1 crash at 0x0400a0af

Author	Message
Randall Parke #1 / 7	Acc 97 SP1 crash at 0x0400a0af We have an NT4 SP3 machine in which MS Access 97 with SP1 has an application error that throws it into Dr Watson while executing basic code at address 0x0400a0af. The exception is 0xC0000005. Another machine running thru that same code doesn't have that problem. We have noticed one thing different about the two machines: They do not have the same revision of msjet35.dll. This is unexpected because both machines have NT SP3 and Office 97 service pak 1 applied. _Both_ machines have MSAccess.exe from the same date and version: 07/11/97 and 8.0.0.4122. They also match for all other dll dates and versions as seen in the Dependency Walker. The machine whose MS Access does _not_ have the application error has msjet35.dll of 12/16/96 and version 3.50.3602.4. Oddly, the machine that does get the application error has a later msjet35.dll whose date matches the date for MSAccess.exe: 07/11/97 and has a later file version/product version: 3.50.3907.5. We have 2 machines which had the following install sequence: NT v4 NT v4 SP3 Office 97 Office 97 SP1 Both have the older version of msjet35.dll The machine that is having the application error had the following install sequence: NT v4 Office 97 NT v4 SP3 Office 97 SP1 Did something else put that newer msjet35.dll there? I need to understand why it isn't always rev'ved. I also need to know whether this later msjet35.dll might be causing the application error. We tried putting the msjet35.dll from the machine that doesn't have the application errors to the one that does and that actually made it worse. It happens sooner. Any ideas?
Sun, 19 Nov 2000 03:00:00 GMT

Manuel A. Lope #2 / 7	Acc 97 SP1 crash at 0x0400a0af This problem, or something very similar, has been coming up a lot with some people (including me) on NT 4 SP3, but the cause is unclear. The only suggestions I have are: 1. Make sure you are using the latest version of Jet (3.51), available on the MS web site. 2. Make sure you are closing all recordsets when done and setting all objects (especially database variables) to nothing after using them. 3. Do not use global variables for database and recordsets. This worked for me on the 0xc0000005 errors, except for an MSINFO32.exe-produced 0xc0000005 error (and it also solved almost all "out of memory" errors), but could be yours has a different cause. Other suggestions include: change or delete your printer driver, and change your video driver (to something simpler). It might not hurt to import all objects into a new database from your old database, and re-compact the database. For a different problem, people have suggested the /decompile switch and then recompiling. P.S. Is your problem on Pentium Pro's? Quote: >We have an NT4 SP3 machine in which MS Access 97 with SP1 has an >application error that throws it into Dr Watson while executing basic code >at address 0x0400a0af. The exception is 0xC0000005. >Another machine running thru that same code doesn't have that problem. We >have noticed one thing different about the two machines: They do not have >the same revision of msjet35.dll. This is unexpected because both machines >have NT SP3 and Office 97 service pak 1 applied. >_Both_ machines have MSAccess.exe from the same date and version: 07/11/97 >and 8.0.0.4122. They also match for all other dll dates and versions as seen >in the Dependency Walker. >The machine whose MS Access does _not_ have the application error has >msjet35.dll of 12/16/96 and version 3.50.3602.4. >Oddly, the machine that does get the application error has a later >msjet35.dll whose date matches the date for MSAccess.exe: 07/11/97 and has a >later file version/product version: 3.50.3907.5. >We have 2 machines which had the following install sequence: > NT v4 > NT v4 SP3 > Office 97 > Office 97 SP1 > Both have the older version of msjet35.dll >The machine that is having the application error had the following install >sequence: > NT v4 > Office 97 > NT v4 SP3 > Office 97 SP1 >Did something else put that newer msjet35.dll there? I need to understand >why it isn't always rev'ved. >I also need to know whether this later msjet35.dll might be causing the >application error. We tried putting the msjet35.dll from the machine that >doesn't have the application errors to the one that does and that actually >made it worse. It happens sooner. >Any ideas?
Mon, 20 Nov 2000 03:00:00 GMT

Randall Parke #3 / 7	Acc 97 SP1 crash at 0x0400a0af Quote: > This problem, or something very similar, has been coming up a lot with some > people (including me) on NT 4 SP3, but the cause is unclear. > The only suggestions I have are: > 1. Make sure you are using the latest version of Jet (3.51), available on > the MS web site. Is this version later than the Service Pack 1 version? We have Service Pack 1 installed. What version does the dll report for v3.51? I have 3.50.3907.5. There are also two earlier versions: v3.50.3428.0 - from Access 97 GA v3.50.3602.4 - from the MSVC v5 install disk BTW, the MSVC v4 version of msjet35.dll will prevent Service Pack 1 from updating to the later version. See: ACC97: MS Office 97 SR-1 Patch Fails to Patch MS Jet Files http://support.microsoft.com/support/kb/articles/q174/3/09.asp On further investigation: 3.51.0623.4 is the latest. So it is even later than the service pak one. Quote: > 2. Make sure you are closing all recordsets when done and setting all > objects (especially database variables) to nothing after using them. Well, I try to do that. But no doubt I've missed a few places.Okay, time to go thru thousands of lines of code with a fine tooth comb. <g> Quote: > 3. Do not use global variables for database and recordsets. > This worked for me on the 0xc0000005 errors, except for an > MSINFO32.exe-produced 0xc0000005 error (and it also solved almost all "out > of memory" errors), but could be yours has a different cause. Geez, I use global variables for recordsets a lot because this code was originally written in Access v2.0 and it isn't possible to pass a recordset to a subroutine and have the subroutine set the recordset variable. Quote: > Other suggestions include: change or delete your printer driver, and change > your video driver (to something simpler). Yes, I've instructed the guy who has Quote: > It might not hurt to import all objects into a new database from your old > database, and re-compact the database. For a different problem, people have > suggested the /decompile switch and then recompiling. > P.S. Is your problem on Pentium Pro's? Yes, PentPro 200. Interestingly it doesn't happen on some PentPro 200's. My own machine (dual PentPro 200 NT4 SP3) has no problem at all with the same database. Quote: > >We have an NT4 SP3 machine in which MS Access 97 with SP1 has an > >application error that throws it into Dr Watson while executing basic code > >at address 0x0400a0af. The exception is 0xC0000005. > >Another machine running thru that same code doesn't have that problem. We > >have noticed one thing different about the two machines: They do not have > >the same revision of msjet35.dll. This is unexpected because both machines > >have NT SP3 and Office 97 service pak 1 applied. > >_Both_ machines have MSAccess.exe from the same date and version: 07/11/97 > >and 8.0.0.4122. They also match for all other dll dates and versions as > seen > >in the Dependency Walker. > >The machine whose MS Access does _not_ have the application error has > >msjet35.dll of 12/16/96 and version 3.50.3602.4. > >Oddly, the machine that does get the application error has a later > >msjet35.dll whose date matches the date for MSAccess.exe: 07/11/97 and has > a > >later file version/product version: 3.50.3907.5. > >We have 2 machines which had the following install sequence: > > NT v4 > > NT v4 SP3 > > Office 97 > > Office 97 SP1 > > Both have the older version of msjet35.dll > >The machine that is having the application error had the following install > >sequence: > > NT v4 > > Office 97 > > NT v4 SP3 > > Office 97 SP1 > >Did something else put that newer msjet35.dll there? I need to understand > >why it isn't always rev'ved. > >I also need to know whether this later msjet35.dll might be causing the > >application error. We tried putting the msjet35.dll from the machine that > >doesn't have the application errors to the one that does and that actually > >made it worse. It happens sooner. > >Any ideas?
Thu, 23 Nov 2000 03:00:00 GMT

Randall Parke #4 / 7	Acc 97 SP1 crash at 0x0400a0af Manuel, We've done additional experiments. The results so far: 1) Doing the /decompile switch gives an error that that option is not recognized. However, after doing that and then Compile And Save All Modules it ran 6 successful batch runs (these are several minute long executions of a lot of Basic code) before hitting the exception on the 7th run. Eventually, several many runs, it started crashing again after about every other run. So I wonder if Access itself is corrupting its own compiled code. 2) Going to the Jet engine v3.51.0623.4 revision did not help any. The frequency of occurrence of the exception is unchanged. 3) Rebooting to VGA and 640x480 caused Access to hit an exception on the very first run! I was amazed that going to the VGA driver made it worse. I was hoping it'd make things better. I've been going thru my code looking for recordsets that don't get closed. I'm next going to try an update of the source code that has a few extra closes added. This one will also do .Close on the Database object at the end of each run. Quote: > This problem, or something very similar, has been coming up a lot with some > people (including me) on NT 4 SP3, but the cause is unclear. > The only suggestions I have are: > 1. Make sure you are using the latest version of Jet (3.51), available on > the MS web site. > 2. Make sure you are closing all recordsets when done and setting all > objects (especially database variables) to nothing after using them. > 3. Do not use global variables for database and recordsets. > This worked for me on the 0xc0000005 errors, except for an > MSINFO32.exe-produced 0xc0000005 error (and it also solved almost all "out > of memory" errors), but could be yours has a different cause. > Other suggestions include: change or delete your printer driver, and change > your video driver (to something simpler). > It might not hurt to import all objects into a new database from your old > database, and re-compact the database. For a different problem, people have > suggested the /decompile switch and then recompiling. > P.S. Is your problem on Pentium Pro's?
Thu, 23 Nov 2000 03:00:00 GMT

Manuel A. Lope #5 / 7	Acc 97 SP1 crash at 0x0400a0af Tip: You may want to add an On Error Resume Next before your recordset.close statements (to avoid a useless error in case you never actually opened them). Also, don't forget to set objects to nothing. Jet 3.51 comes with its own compact utility which is better at reporting problems. Office 97 SP 2 is soon to be released, but I doubt that will offer any help. Quote: >Manuel, >We've done additional experiments. The results so far: >1) Doing the /decompile switch gives an error that that option is not >recognized. However, after doing that and then Compile And Save All Modules it >ran 6 successful batch runs (these are several minute long executions of a lot >of Basic code) before hitting the exception on the 7th run. > Eventually, several many runs, it started crashing again after about every >other run. > So I wonder if Access itself is corrupting its own compiled code. >2) Going to the Jet engine v3.51.0623.4 revision did not help any. The frequency >of occurrence of the exception is unchanged. >3) Rebooting to VGA and 640x480 caused Access to hit an exception on the very >first run! > I was amazed that going to the VGA driver made it worse. I was hoping it'd >make things better. >I've been going thru my code looking for recordsets that don't get closed. I'm >next going to try an update of the source code that has a few extra closes >added. This one will also do .Close on the Database object at the end of each >run. >> This problem, or something very similar, has been coming up a lot with some >> people (including me) on NT 4 SP3, but the cause is unclear. >> The only suggestions I have are: >> 1. Make sure you are using the latest version of Jet (3.51), available on >> the MS web site. >> 2. Make sure you are closing all recordsets when done and setting all >> objects (especially database variables) to nothing after using them. >> 3. Do not use global variables for database and recordsets. >> This worked for me on the 0xc0000005 errors, except for an >> MSINFO32.exe-produced 0xc0000005 error (and it also solved almost all "out >> of memory" errors), but could be yours has a different cause. >> Other suggestions include: change or delete your printer driver, and change >> your video driver (to something simpler). >> It might not hurt to import all objects into a new database from your old >> database, and re-compact the database. For a different problem, people have >> suggested the /decompile switch and then recompiling. >> P.S. Is your problem on Pentium Pro's?
Sun, 26 Nov 2000 03:00:00 GMT

Randall Parke #6 / 7	Acc 97 SP1 crash at 0x0400a0af Quote: > Tip: You may want to add an On Error Resume Next before your recordset.close > statements (to avoid a useless error in case you never actually opened > them). Also, don't forget to set objects to nothing. How do you set an object to nothing? What value to assign to them? Is this just Database objects you are referring to? Or Recordset objects too? Do you close Database objects? I just went thru and made sure I'm closing all Recordset objects. Quote: > Jet 3.51 comes with its own compact utility which is better at reporting > problems. Office 97 SP 2 is soon to be released, but I doubt that will > offer any help. You don't think they are going to fix this? Any idea why?
Tue, 28 Nov 2000 03:00:00 GMT

Manuel A. Lope #7 / 7	Acc 97 SP1 crash at 0x0400a0af Extra tip: delete all tmp files and folders in c:\Temp referring to Access or jet that are old (or that exist while Access is not running). Quote: >How do you set an object to nothing? What value to assign to them? nothing e.g. Set rst = nothing Quote: >Is this just Database objects you are referring to? Or Recordset objects too? All objects (i.e. everything you opened with Set, such as databases, recordsets, querydefs, tabledefs, etc.). Quote: >Do you close Database objects? I just went thru and made sure I'm closing all >Recordset objects. YES. Close all database objects (the only exception would be the CurrentDB(), but it's harmless if you do close it: Access ignores a close statement on database variables set to CurrentDb without generating an error). Quote: >>Office 97 SP 2 is soon to be released, but I doubt that will >> offer any help. >You don't think they are going to fix this? Any idea why? I'm only judging from the silence in the KnowledgeBase about it, which makes me guess a fix, if there is one, won't be until Office 9 late this year or early next year.
Wed, 29 Nov 2000 03:00:00 GMT

Page 1 of 1

[ 7 post ]