Hej!

Jag har strulat med följande problem i ett års tid.

Programmet är skrivet i vb6 och går som en service (använder ntsvc.ocx). För databas access används ADO.

Databasen är liten och består av ca 20 tabeller med ett par poster i varje tabell. Ca 1 gång/timme accessas databasen.

Efter ca 2-3 veckor händer följande i event loggen:

2003-02-07 19:51:36 COM+ Error Executive 4199 N/A GOLDENEYE The COM+
Services DLL (comsvcs.dll) was unable to load because allocation of thread local storage failed.
Process Name: EasyCallSrv.exe
Error Code = 0x80070008 : Not enough storage is available to process this command.
COM+ Services Internals Information:
File: .\comsvcs.cpp, Line: 289


Programmet fortsätter att snurra men ger felmeddelande enligt nedan 1 gång/timme:

2003-02-07 20:00:36 EasyCall Error None 109 N/A GOLDENEYE Error:
[-2147418113] Catastrophic failure (Module: ProcessJourList)

Efter omstart av tjänsten fungerar programmet igen.


Några fakta:
- programmet har funnits i ett par år och är spritt i ca 50 ex.
- i början när de flesta körde nt4 (srv eller wrk) var det aldrig några problem
- numera kör de flesta win 2000 (srv eller wrk), men bara 4-5 st har problem.
- win2000 SP3 hjälper inte
- har försökt att stressa fram felet på en "problem-dator" genom att accessa databasen 1 gång/minut istället för 1 gång/timme. Men programmet har snurrat ett par veckor utan problem.
-alla moduler i programmet har error-hantering och loggning till event loggen. Inga fel finns i event loggen innan com+ meddelandet.

På följande sida finns folk med samma problem
http://www.tek-tips.com/gviewthread.cfm/lev2/4/lev3/30/pid/787/qid/150767


Är det någon av er som haft ett liknande problem? Har det något med ADO att göra?
Kan det vara något med MDAC (är ett mörker för mig)? Finns det något enkelt sätt att ta reda på vilken MDAC-version som används (gillar inte att köra cc.exe, som dessutom kräver en omstart av datorn!)

Har gått igenom koden flera gånger för att kolla så allt öppnas/stängs på ett riktigt sätt.

Tips/idéer om vad som kan vara fel tages tacksamt emot.

mvh,
Leif

Helt klart låter det som en differens i någon extern com-komponent som du kanske anropar. Du nämner ADO där det nu finns 2.7 som senaste version och den du troligen adresserar är 2.5 eftersom du säger att den gått på NT4.

På www.microsoft.com/data finns ett program som du kan hämta och se vilken eller vilka versioner av ADO som du använder på servern.

Mitt spontana förslag är att uppgradera din komponent att göra ADO-anropen mot ADO 2.6 sp2 (tror jag det är). För att ådstakomma detta så avmarkerar du din referens i ditt projekt och återmarkerar det med den nya versionen.

Om nu plötsligt alla maskiner får samma problem är det definitivt ADO som ställer till det för dig. Du kan då se till att du installerar ADO 2.5 (om det är den version du utvecklat med) på samtliga servrar som har problem. Du kan installera ADO 2.5 ovanpå befintliga servrar även om 2.6 eller 2.7 också är installerad.

Hoppas detta hjälper dig i felsökningen, lycka till

Hej Leif,

Ett enkelt sätt att kolla MADC-version är att kolla vilken version du har på filen MSADO15.DLL. Leta upp filen i Utforskaren (C:\Program Files\Common Files\SYSTEM\ADO) och högerklicka på den. Välj "Egenskaper" och sedan fliken Version. Om versionsnummret börjar på 2.5 så körs version 2.5 och om versionsnummer börjar på t.ex. 2.71 så körs version 2.7 SP1.

Vill du själv kolla filversioner kan du gå till
http://support.microsoft.com/default.aspx?scid=/servicedesks/fileversion/dllinfo.asp&SD=MSDN&FR=0

Du nämner inte vilken databas du använder ?
Lägg på de senaste servicepackarna.
SP3 för SQL Server 2000 och MSDE och SP6 ? för JET (Access)

Se också till att du har kompilerat din VB app. med SP5 och installera den igen.
Gå igenom din kod och se till att du stänger alla objekt och sedan sätter alla object till Nothing, speciellt då för databasobjecten.

Exempel:
<code>
Set conn = ADODB.Connection.
Set rs = ADODB.Recordset
' Utför databasoperationen här
.......
' Städa upp
rs.Close
Set rs = Nothin
conn.Close
Set conn = Nothing
</code>

Och som Pelle säger, senaste MDAC är 2.7 och till och med SP1 där.
Prova att lägga på den och se om problemet försvinner.

Micke - Microsoft

Tack för era kommentarer.

Ska kontrollera/testa MDAC på en dator som krångar mycket. Dock tar det 2-3 veckor mellan varje feltillfälle (förutsatt att inte kunden startar om datorn däremellan).

En konstighet är att det inte går att stressa fram felet genom att ändra den procedur som anropar databasen regelbundet till att köras 1 gång/minut istället för 1 gång/timme.

mvh
Leif

Hej igen,

Kollade just MDAC-version på en problem-dator vs. en med inga problem. Båda är 2000 server SP3 och båda kör 2.53.6200.0

Jag kör vb med SP4 och ADO2.5. Vad jag förstår så är ADO 2.5 standard för en 2000 installation. På NT4-tiden skickade jag med mdac_typ.exe (2.5) som de flesta var tvugna att installera.

Om jag skulle uppdatera till SP5 och använda en senare version av ADO, vilken fil/filer måste jag då ta med i installations-programmet.

Jag ser att jag öppnar databasen lite annorlunda mot vad du beskriver Mikael.
Exempel:
Dim ad As ADODB.Connection
Dim ar As ADODB.Recordset

Set ad = New ADODB.Connection
Let ad.ConnectionString = DbConnString
ad.Open

Set ar = New ADODB.Recordset
ar.CursorType = adOpenStatic
ar.LockType = adLockReadOnly ' or adLockOptimistic
ar.Open "SLM_ExcPerm", ad, , , adCmdTable
.....

ar.Close
ad.Close

Jag vill minnas att jag läst någon gång om de olika alternativen, men att flertalet i denna diskussion förordade det som jag använder ??

När det gäller att stänga så provade jag att köra med = nothing för ca 1 år sedan, men eftersom problemet kvarstod så tog jag bort det igen.

mvh,
Leif

I systemdokument/servicepacks till vänster finns länkar på de senaste versionerna. mdac_typ.exe som du sen drar hem, se till att den läggs i din vs-katalog så den kommer med ordentligt när du kör package & deployment.

Rörande din kod - det enklaste för dig när du kör en sp är följande kod eftersom du inte verkar behöva returnera några poster:

<code>
Dim ad As ADODB.Connection
Set ad = New ADODB.Connection

ad.open DbConnString
ad.execute ("SLM_ExcPerm")
set ad = nothing
<code>

kommer det dock poster tillbaks, testa då detta:

<code>
Dim ad As ADODB.Connection
Set ad = New ADODB.Connection

ad.open DbConnString
set rst = ad.execute ("SLM_ExcPerm 1,2,3,'kalle'")
set ad = nothing
</code>

I rst har du nu ett recordset innehållade det som returnerades i din sp

I tillegg til andra nämnde råd her om at använda rett MDAC version, vill jag också passe på at nevne at globale variabler kan vara en del av problemet.

Det her e troligen inte et COM+, men hellre et minnesproblem i din applikasjon. Felet indikerer at du går tom for Thread Locale Storage (TLS). Derför kan inte comsvcs.dll laddes in i din process og felmedelande blir loggad.

På en win2k burk har du ungefär 1000 slike slots tilgjengelige tilsammans för alla processer på maskinen. Både COM+ og VB bruker TLS. VB användar det för at holla koll på globale variabler. Har du sådanne? Det bör absolutt undvikas i COM+, asp och andra server applikasjoner.

Et exempel på sådanna problem med globala variabler är om du bruker dom til å holde ADO objekter.

Du säger også at om du aksesserer databasen 1 gong i minutet eller timmen spelar ingen roll. Istället skulle jag gissa på at det i stället er et samband mellan antall samtidige användare av applikasjonen.

Om inte du användar globale variabler, kanske du användar en komponent som gjör det?

Du kan använda TlsAlloc API:et för at selv allokere TLS slots. Om det går bra, så vil den returnere vilken index slot'en har. 1088 er max. Efter det får du samma typ av felmeddelande.

Tack än en gång för era kommentarer.

När det gäller globala variabler har du alldeles rätt Gunnar - jag använder en hel del globala variabler.

Och ganska många är arrayer. Dock är det bara strängvärden och olika räknar-värden som lagras undan i dessa, så jag kan inte riktigt se vad det skulle ha med ADO att göra.

Programmet är ett larminsamlingssystem och har i princip inga användare. Enda gången är då någon kör ett konsolprogram för att konfigurera/ändra vissa parametrar. Kod är inlagt så det går inte att starta konsolen 2 gånger på samma dator. Larm från externa system tas in genom att läsa en fil - så här kan det rimligen inte finnas några problem. En kund har också sagt att problemet uppstår även om det inte kommer några larmar.

Det finns även en "remote konsol" till programmet som inte är särskilt snyggt gjord, dvs från remote konsolen accessar man databasen via en uppmappad drive. Det är väldigt få som använder denna konsol, men jag har lite indikationer på att en del av de som har problem faktiskt använder konsolen.

Min största problem är att jag inte har lyckats finna något sätt att stressa fram problemet - vilket leder till en hel del subjektiva intryck och bedömningar som försvårar felsökningen.

Finns det något sätt att mäta TLS, för att se hur/när det ökar? Har tittat lite i Performance Monitor men hittar inget. Vore mycket tacksam för tips om hur jag kan felsöka.

Trevlig helg,
Leif

Det fins ingen performance monitor etc för at ta reda på hur många slots e lediga. Testa med den her koden så ser du hur det fungerar.

Skapa et nytt VB projekt med ett formulär. placera två knappar och en listbox der. Klistra inn koden.

<code>
Private Declare Function TlsAlloc Lib "kernel32" () As Long
Private Declare Function TlsFree Lib "kernel32" (ByVal dwTlsIndex As Long) As Long
Private Declare Function TlsGetValue Lib "kernel32" (ByVal dwTlsIndex As Long) As Long
Private Declare Function TlsSetValue Lib "kernel32" (ByVal dwTlsIndex As Long, lpTlsValue As Any) As Long

Const TLS_OUT_OF_INDEXES = &HFFFFFFFF
'På Win2k er det max 1088 slotar
' om du krevjer mer enn det så returnerer TlsAlloc TLS_OUT_OF_INDEXES

Private Sub Command1_Click()
Dim Tagit As Long

Tagit = TlsAlloc
If Tagit = TLS_OUT_OF_INDEXES Then
MsgBox "ERROR: Ingen Tls slottar tilgjengeliga"
Else
List1.AddItem (Tagit)
End If
End Sub

Private Sub Command2_Click()
If List1.SelCount = 1 Then
TlsFree (Int(List1.Text))
List1.RemoveItem (List1.ListIndex)
End If
End Sub
</code>

Start om maskinen når du er klar med dette forsøket! Om du glömmer at frigjöra alle TLS slots så "forlorar" du systemressurser.

Hej Gunnar,

Har gjort lite tester med din kod. Bland annat har jag kört koden på en av problem-datorerna som just nu snurrat i 2 veckor - det returnerade värdet är 5,6,7... Det går även bra att ta bort dom ock allokera på nytt.

Samma resultat (5,6,7 etc.) får jag också på en dator som är nyuppstartad.

Kan det verkligen ha något med detta att göra?

mvh,
Leif

Problemet är bekräftat av Microsoft i KB-artikel 819989, och en fix finns tillgänglig.

Puh...

mvh,
Leif