8

J'ai toutes les extensions désactivées, et seulement 1 projet Sql ouvert. Pourtant, Visual Studio se bloque chaque fois que je ferme un fichier SQL.Visual Studio se bloque lors de la fermeture des fichiers .SQL

Versions affectées:

  • 2017 Enterprise
  • 2015 Enterprise

Au cours de cette "hang time" Visual Studio possède un statut ne répond pas.

Il semble également que la durée pendant laquelle il reste verrouillé est corrélée au nombre de fichiers fermés/ouverts.

EDIT: avec devenv dans reproductible SafeMode

pensées?

+0

Avez-vous essayé devenv/SafeMode? Une autre option consisterait à attacher un autre Visual Studio au premier pour vérifier la callstack pendant que vous fermez le premier, peut-être qu'il se connecte quelque part et obtient des délais. –

+0

SafeMode produit le même résultat. J'ai utilisé un moniteur de connexion pour voir s'il atteignait l'extérieur et pendait. Mais pas de dés. Bonne idée cependant! – pimbrouwers

Répondre

19

Ouvrir MS Ticket: https://developercommunity.visualstudio.com/content/problem/67789/visual-studio-hangs-when-closing-sql-files.html

La vraie solution viendra avec une mise à jour à partir de MS. Pour l'instant, cependant, la désactivation de ma participation au programme d'amélioration de l'expérience Visual Studio semblait le résoudre.

Vous pouvez vérifier si vous êtes inscrit ou non à ce programme en cliquant sur Aide -> Envoyer des commentaires -> Paramètres (en 2017, je ne sais pas pour 2015).

+0

Incroyable. Super trouvaille frère! – pimbrouwers

+0

MERCI. TOI. TRÈS. BEAUCOUP!!! –

+1

@RuslanK. heureux d'entendre cela a aidé quelqu'un d'autre! – pimbrouwers

0

Il semble que VS génère un événement Rapport d'erreurs Windows (REH) lorsqu'une fenêtre de fichier sql est fermé:

Fault bucket , type 0 
Event Name: VisualStudioNonFatalErrors2 
Response: Not available 
Cab Id: 0 

Problem signature: 
P1: devenv.exe 
P2: 15.0.26430.12 
P3: vs.platform.hwndwrapper.destroy-window-error 
P4: unknown 
P5: Microsoft.VisualStudio.Shell.15.0 
P6: Microsoft.VisualStudio.PlatformUI.HwndWrapper.DestroyWindowCore 
P7: unknown 
P8: unknown 
P9: unknown 
P10: unknown 

Ces corrèlent à chaque tentative de fermer une fenêtre. Décocher les boîtes de construction/déploiement dans le gestionnaire de configuration ne semble pas aider (je cours VS 2017 Enterprise).

L'exécution procmon montre 11 secondes de retard sur ma machine à fermer une seule fenêtre après la poignée wermgr.exe est fermée:

12:19:31.2071581 AM devenv.exe 6564 CloseFile C:\Windows\SysWOW64\wermgr.exe SUCCESS 
12:19:32.7423468 AM devenv.exe 6564 Thread Exit  SUCCESS Thread ID: 16288, User Time: 0.0000000, Kernel Time: 0.0000000 
12:19:36.6511179 AM devenv.exe 6564 Thread Create  SUCCESS Thread ID: 8576 
12:19:38.1531428 AM devenv.exe 6564 Thread Exit  SUCCESS Thread ID: 8576, User Time: 0.0000000, Kernel Time: 0.0000000 
12:19:42.7939996 AM devenv.exe 6564 Thread Create  SUCCESS Thread ID: 12052 
12:19:42.7952451 AM devenv.exe 6564 Thread Exit  SUCCESS Thread ID: 12052, User Time: 0.0000000, Kernel Time: 0.0000000 
12:19:42.7953980 AM devenv.exe 6564 Thread Create  SUCCESS Thread ID: 6892 
12:19:42.7984705 AM devenv.exe 6564 RegQueryKey HKLM SUCCESS Query: HandleTags, HandleTags: 0x0 

Cela semble être un bug de produit sans solution connue à ce moment .

+0

Incroyable perspicacité mon homme. Peut-être devrions-nous répliquer ce fil dans le forum des erreurs VS? – pimbrouwers

+0

Je suis assez nouveau ici ... pas sûr de la meilleure façon de le faire. – toddg26

+0

pas trop de soucis, j'ai soumis un billet pour cela. – pimbrouwers

0

La solution pour moi était:

  1. Mise à jour ces extensions:

    • ReadyRoll pour VS2017
    • de base SQL Prompt
  2. Désactivation/réactivation suivantes extensions sur VS 2017 Enterprise:

    • ReadyRoll pour VS2017
    • de base SQL Prompt
    • Rechercher SQL

Alors que je tentais de comprendre quelle extension a été l'origine du blocage, je ne pouvais pas identifier celui spécifique . Quoi qu'il en soit, cette approche a fonctionné et j'ai les trois extensions activées maintenant.

Tout cela est très étrange, car j'ai quitté mon poste de travail le vendredi dernier, avec VS ouvert. Et ce lundi matin, il a juste commencé à se bloquer en essayant d'ouvrir n'importe quel fichier .sql, même lorsque le fichier était vide.