het aanroepen van een nieuw SqlConnection () hangt programma

Deze heeft me stumped. Ik probeer niet eens verbinding te maken met een database. Wanneer deze code op de regel komt waar ik een nieuw SqlConnection-object instantieer, blijft het daar hangen en wordt er geen uitzondering of iets anders gegenereerd. Ik heb geprobeerd het te compileren voor 2.0. 3.5 en 4.0, en ze hangen allemaal. Natuurlijk werkt het ook op mijn machine en die van jou. Maar ik probeer deze code op een Windows Server 2008 x64-server uit te voeren, en hij zal niet wijken.

// example.cs
using System;
using System.Data;
using System.Data.SqlClient;

public class MainClass {
    public static void Main(string[] args) {
        Console.WriteLine("start");
        SqlConnection conn = new SqlConnection();//hangs here
        Console.WriteLine("finish");             //never makes it here.
    }
}

compilatie (2.0): c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ csc.exe example.cs

6
probeer een verbindingsreeks door te geven aan de SqlConnection-klasse.
toegevoegd de auteur amrfaissal, de bron
Probeer meer informatie te vinden over de omgeving waarop het actief is, log Environment.Version in op de console en rapporteer het terug? Bevat de code ook iets anders dan wat je gepost hebt?
toegevoegd de auteur wal, de bron
@ CrackingWise Het is niet de bedoeling om het te laten hangen, alleen proberen om meer informatie te vinden. Dus wat was de uitvoer van Environment.Version ? Moet iets zijn als: 2.0.50727.5448
toegevoegd de auteur wal, de bron
Controleer uw antivirus.
toegevoegd de auteur John Saunders, de bron
Deze code hangt niet voor mij.
toegevoegd de auteur kol, de bron
@ p.campbell Je hebt gelijk, sorry. Ik heb dat gedeelte overgeslagen.
toegevoegd de auteur kol, de bron
Het lijkt erop dat dit gewoon zou moeten werken. Maakt het uit of je Conn eerst verklaart, buiten Main? Of als u het als niet-statisch declareert (bijvoorbeeld eerst een exemplaar van MainClass maken? Net als een verkenning van waar het voorkomt en waar niet.
toegevoegd de auteur gjvdkamp, de bron
Is het gedrag hetzelfde als u het richt op 32- of 64-bits?
toegevoegd de auteur Rob, de bron
@wal: ik heb de code toegevoegd van msdn.microsoft.com/en- us/library/system.environment.aspx om de systeemomgeving te dumpen (met namen gewijzigd om de schuldigen te beschermen). Het blijft hangen bij "nieuwe SqlConnection ()". En hoe vreemd het ook lijkt, nee er is niets anders in deze code, wat ik schreef is wat is gebroken.
toegevoegd de auteur CrackingWise, de bron
@FGraviton: ik heb het geprobeerd met en zonder een verbindingsreeks. Dat is niet het probleem.
toegevoegd de auteur CrackingWise, de bron
@Rob: Ik heb geprobeerd te compileren met de opdrachtregelopties/platform: anycpu,/platform: x64 en/platform: x86. Ze hangen allemaal.
toegevoegd de auteur CrackingWise, de bron
Ja, het hangt met of zonder een verbindingsreeks.
toegevoegd de auteur CrackingWise, de bron

5 antwoord

Het is waarschijnlijk een defecte prestatiemeter waar het om gaat. Ik had dit probleem en ik gebruikte Procmon om te detecteren wat er gebeurde. Mijn .NET-toepassing is opgehangen bij het laden van de registersleutels voor de prestatiemeter. ".NET Data Provider for SqlServer"

Ik heb de teller gelost met het volgende commando om het te laten werken:

unlodctr ".NET Data Provider for SqlServer"
6
toegevoegd
". NET Memory Cache 4.0" is een andere die kan worden beïnvloed - niet zeker hoe deze tellers beschadigd raken.
toegevoegd de auteur SliverNinja - MSFT, de bron
Bedankt - dit heeft me geholpen toen ik dit probleem tegenkwam!
toegevoegd de auteur Konrad, de bron

Je installatie moet worden verbroken. De code doet helemaal niet echt iets vitaals, dus er is geen reden om daar te blijven hangen.

De constructor SqlConnection doet dit:

public SqlConnection() {
  this.ObjectID = Interlocked.Increment(ref SqlConnection._objectTypeCount);
  base();
  GC.SuppressFinalize(this);
  this._innerConnection = DbConnectionClosedNeverOpened.SingletonInstance;
}

Dus, het verhoogt een variabele, kopieert het naar een eigenschap, roept de basisconstructor aan, verwijdert het object uit de finaliserwachtrij en kopieert een referentie. Dat is alles.

De basis ( DbConnection ) constructor doet dit:

protected DbConnection() {
}

Er zit dus niets in dat feitelijk iets doet dat gerelateerd is aan een echte databaseverbinding. Dat gebeurt allemaal wanneer u daadwerkelijk een verbinding opent.

Uw programma kan net zo goed achter de eerste Console.WriteLine -oproep hangen en zelfs niet zover komen als het maken van het SqlConnection -object.

2
toegevoegd
Ik ben het ermee eens dat een mislukte installatie mijn # 1 gok is. Het is redelijk snel en gemakkelijk om opnieuw te installeren .Net Ik zou dat eerst proberen. Heeft u .net2,3.5 en and4 nodig? Zo niet, installeer dan alleen degene die u nodig hebt (beperk mogelijke problemen zo veel mogelijk)
toegevoegd de auteur wal, de bron
Waarom het downvote? Als je niet uitlegt wat het is waarvan je denkt dat het fout is, kan het het antwoord niet verbeteren.
toegevoegd de auteur Guffa, de bron
@kol: het is geen property, het is een readonly statisch veld.
toegevoegd de auteur Guffa, de bron
Is er niet iets gaande in de getter van het SingletonInstance-pand?
toegevoegd de auteur kol, de bron
Interessant probleem, de andere dingen om naar te kijken zijn de statische constructors: SqlConnection, SqlConnectionFactory, DbConnectionClosedNeverOpened, ...
toegevoegd de auteur Simon, de bron
Ik betwijfel of het een kapotte installatie is, dat zou betekenen dat ALLE mijn .NET installaties kapot zijn (2.0, 3.0, 3.5 en 4.0). En het hangt niet op de console. Schrijflijn, daar heb ik voor getest.
toegevoegd de auteur CrackingWise, de bron

Stel 2 stappen voor:

  • reset IIS om alle verbindingspools te wissen. (Misschien Windows opnieuw opstarten?)
  • verander de code in een met -instructie:
  public static void Main(string[] args) { 
    Console.WriteLine("start"); 
    using (SqlConnection conn = new SqlConnection())
    {
          Console.WriteLine("middle");              
    }
    Console.WriteLine("finish");             
} 

Kan een andere app van die machine andere SqlConnection-objecten maken?

Het is duidelijk een milieu probleem, omdat uw geposte code op een andere machine werkt. Vermoed dat het een kantelpunt voorbij is, en de gebruikende zal dit in de toekomst helpen verdedigen.

1
toegevoegd
@ CrackingWise: hoe zit het met het resetten van IIS, was dat mogelijk?
toegevoegd de auteur p.campbell, de bron
Interessant. Waarom denk je dat 'gebruiken' helpt? Hoe dan ook, wat doet de parameterloze ctor precies? Iemand zou het kunnen controleren met .NET Reflector.
toegevoegd de auteur kol, de bron
Ik heb de machine nog niet opnieuw opgestart, het is een productieserver. Maar als je het schrijft zoals je suggereert, haalt het nooit "midden".
toegevoegd de auteur CrackingWise, de bron
Ik heb IIS (w3svc en iisadmin) volledig opnieuw op de server opnieuw gestart, maar geen dobbelstenen. Dit is niet echt verrassend, omdat ik deze exe vanaf een opdrachtregel gebruik, niet via een ASP.NET AppPool. En het is ook geen beveiligingsprobleem, omdat veel andere code zal worden uitgevoerd, gewoon niet "nieuwe SqlConnection ()".
toegevoegd de auteur CrackingWise, de bron

Solution found! I had the same problem on many PCs. Framework 4.5.2

Voer deze opdracht uit als admin in CMD:

unlodctr ".NET Data Provider for SqlServer"

Mogelijk moet u het met de hand typen omdat copy pasta met citaten niet goed werkt.

Bron:

http://askproblem.com/question/calling-new-sqlconnection-hangens- programma/

I know this thread is old, but maybe someone else will get this error. It’s probably a broken performance counter which is the issue. I had this problem and I used Procmon to detect what happened. My .NET application hanged when it >came to loading the registry keys for the performance monitor “.NET Data Provider for SqlServer” I unloaded the counter with the following command to get it working: C: Windowsinf>unlodctr “.NET Data Provider for SqlServer”

1
toegevoegd
Dit is slechts een herhaling van een antwoord rechts op deze pagina ...
toegevoegd de auteur Peter O., de bron

Ik had hetzelfde probleem en het begon te werken nadat ik 1. Het doelraamwerk had gewijzigd van 4.0 naar 3.5 en 2. de foutopsporingsinstellingen had veranderd naar x64 in de visuele studio.

0
toegevoegd