Pervasive SQL ODBC Keeps crashing w3wp.exe
I run a web service on a Windows Server 2003 SP2 box running ASP.net 2.0 accessing Pervasive 9.71.10.0 via ODBC.
I have several installations with a similar configuration but on this particular one, it seems that when more than one person tries to access the Web service at a time I get an IIS Worker Process - error (see attachment) This shuts down the ODBC connection to Pervasive SQL for a time, and then without intervention it will start working again.
There is a variance from this installation compared to all of my working installations, as follows:
On this installation IIS is running on the Pervasive server, on all other installation I have used two separate machines. So normally I specify the ip address of the data server in my connection string. For this one I am using 127.0.0.1.
Also because I normally use 2 machine on the network to accomplish this connection I normally have a DSN Client ODBC interface on the IIS Server and an DSN Engine ODBC Interface on the Data server. So on this installation I am only using the DSN Engine ODBC Interface.
The other thing that this installation has that others do not is large records compared to the other installations. 200000 records compared to 20000.
The error points me to some log files that do not exist:
accompat.txt and w3wp.exe.mdmp they are supposed to be in my profile's directory.
This is from the system event viewer:
The system has called a custom component and that component has failed and generated an exception. This indicates a problem with the custom component. Notify the developer of this component that a failure has occurred and provide them with the information below.
Component Prog ID: 1[ODBC][Env ea814e8]
Method Name: IDispenserDriver::CreateRe
Process Name: w3wp.exe
Exception: C0000005
Address: 0x0EBF37BA
Call Stack:
w3odbcci!ConnectDlg + 0xffea
+ 0x190aaf5
odbcerror.jpg
I have several installations with a similar configuration but on this particular one, it seems that when more than one person tries to access the Web service at a time I get an IIS Worker Process - error (see attachment) This shuts down the ODBC connection to Pervasive SQL for a time, and then without intervention it will start working again.
There is a variance from this installation compared to all of my working installations, as follows:
On this installation IIS is running on the Pervasive server, on all other installation I have used two separate machines. So normally I specify the ip address of the data server in my connection string. For this one I am using 127.0.0.1.
Also because I normally use 2 machine on the network to accomplish this connection I normally have a DSN Client ODBC interface on the IIS Server and an DSN Engine ODBC Interface on the Data server. So on this installation I am only using the DSN Engine ODBC Interface.
The other thing that this installation has that others do not is large records compared to the other installations. 200000 records compared to 20000.
The error points me to some log files that do not exist:
accompat.txt and w3wp.exe.mdmp they are supposed to be in my profile's directory.
This is from the system event viewer:
The system has called a custom component and that component has failed and generated an exception. This indicates a problem with the custom component. Notify the developer of this component that a failure has occurred and provide them with the information below.
Component Prog ID: 1[ODBC][Env ea814e8]
Method Name: IDispenserDriver::CreateRe
Process Name: w3wp.exe
Exception: C0000005
Address: 0x0EBF37BA
Call Stack:
w3odbcci!ConnectDlg + 0xffea
+ 0x190aaf5
odbcerror.jpg
ASKER
There are about 16GB of DAT files on this server. Some of which are up to to 2 to 4 GB alone. I am not normally accessing these big files, but I do query a couple in a join that are a combined 400MB.
Hi,
it's a fault in the odbc connector dll - you need to contact the vendor for support. There is nothing that amyone else can do about it :-(
Cheers.
it's a fault in the odbc connector dll - you need to contact the vendor for support. There is nothing that amyone else can do about it :-(
Cheers.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Here is the log file, the two entires in there may be unrelated, earlier in the day I was trying to run an update query and I "canceled" it twice.
pvsw.log
pvsw.log
ASKER
Here is my connection string:
Dsn=PDSData2;servername=19
PDSData2 is the name if the Client DSN Interface on the webserver which is also the Pervasive server. When I created that Client interface I used the ip address instead of the server name.
PDSDATA is the Dataset set I am accessing on the pervasive server.
I thought I had it fixed yesterday, I originally only had the Engine DSN interface and was referencing it in the Connection string. So I created a Client DSN Interface on the same machine and I referenced it. All day long I was able to access it with at least 4 close-to simultaneous users.
I can't say for sure this is caused by multiple users, just that every time it happens it seems two people were accessing it around that time. This morning when it crashed I was just accessing it with two separate computers, I was able to do two semi-simultaneous accesses but on the third one, only the first one went through.
I was able to get the accompat.txt and hdmp files this time by copying them before I sent the eroor report to microsoft. I have attached it.
Again the only thing different between this and my other installations is that this server is a shared web-server and Pervasive server, where usually they are separate servers. Also I think this is a virtual instance of windows 2003.
manifest.zip
Dsn=PDSData2;servername=19
PDSData2 is the name if the Client DSN Interface on the webserver which is also the Pervasive server. When I created that Client interface I used the ip address instead of the server name.
PDSDATA is the Dataset set I am accessing on the pervasive server.
I thought I had it fixed yesterday, I originally only had the Engine DSN interface and was referencing it in the Connection string. So I created a Client DSN Interface on the same machine and I referenced it. All day long I was able to access it with at least 4 close-to simultaneous users.
I can't say for sure this is caused by multiple users, just that every time it happens it seems two people were accessing it around that time. This morning when it crashed I was just accessing it with two separate computers, I was able to do two semi-simultaneous accesses but on the third one, only the first one went through.
I was able to get the accompat.txt and hdmp files this time by copying them before I sent the eroor report to microsoft. I have attached it.
Again the only thing different between this and my other installations is that this server is a shared web-server and Pervasive server, where usually they are separate servers. Also I think this is a virtual instance of windows 2003.
manifest.zip
ASKER
This seems to have the most information about the crash from the hdmp file
error-part.txt
error-part.txt
ASKER
After the crash first thing this morning, it resets itself as usual and became available again after about 45 minutes.
Now, like yesterday, I can't crash it even hitting it four sessions at a time.
Now, like yesterday, I can't crash it even hitting it four sessions at a time.
ASKER
New error today
deperror.jpg
deperror.jpg
ASKER
the detail from this error
deperror-detail.jpg
deperror-detail.jpg
ASKER
here are the new hdmp files
Errordumpfiles.zip
Errordumpfiles.zip
ASKER
...also it was doing this before on 9.52 so I had them upgrade to 9.71. No change.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks Bill, I'm on vacation but I will check into some of these things when I get back in.
ASKER
What I ended up doing was a setting the Application pool in IIS. The Recycle worker process was set to recycle every 90 minutes. I checked my other installs where I've never had this problem and they were set for every 29 hours. This also seemed strange so I set this one to recycle twice a day, once at 1 am, and again at 5:00 am. This has stopped the crashing. I don't fully understand why, but it has.
ASKER
Most of the suggestions while not the solutions led me to dig deeper into the system and led me to the final slef-solution
ASKER
serverprops1.jpg
serverprops2.jpg