Home Dashboard Directory Help
Search

Crash when opening a solution by Frank Heimes


Status: 

Closed
 as Not Reproducible Help for as Not Reproducible


1
0
Sign in
to vote
Type: Bug
ID: 716363
Opened: 1/3/2012 6:39:00 AM
Access Restriction: Public
Moderator Decision: Sent to Engineering Team for consideration
0
Workaround(s)
view
0
User(s) can reproduce this bug

Description

1) Start and use VS2010 for a few hours; open and close several solutions.
2) Open a solution
> Application crash
Details
Sign in to post a comment.
Posted by Microsoft on 3/23/2012 at 3:29 AM
Thank you for submitting feedback on Visual Studio 2010 and the .NET Framework. Since we have not heard back from you we will close the issue. If you need further assistance on this or any other pre-release product issues in the future, please feel free to contact us and we will be happy to help.
Posted by Microsoft on 3/16/2012 at 5:18 AM
Hello,

Sorry for bothering again. Is there any update?

It would be greatly appreciated if you could provide us with that information as quickly as possible.

Thank you
Posted by Microsoft on 3/6/2012 at 3:41 AM
Hi DRFGHDE,

Sorr for delay.

Could you please try to use Visual Studio to get a dump with a heap so that we can get a better call stack?

Thanks again for your efforts and we look forward to hearing from you.
Posted by Frank Heimes on 2/26/2012 at 9:39 AM
I can not reliably pinpoint the extension that causes the trouble (how could I?).
The previous comments in this thread make the modules "VSCommands 2010" and "VisualAssistX" the prime suspects.
Posted by Microsoft on 2/24/2012 at 4:11 PM
Hi,

Thanks for reporting the issue. The crash is still being investigated meanwhile the original exception is because one of the extensions is calling VCFilter::get_UrlBehavior which has been deprecated. If you can identify the extension please let us know and we can work with the owner and advise not to use the API.

Thanks,
Amit Mohindra
Visual C++ Team.
Posted by Frank Heimes on 2/6/2012 at 9:12 AM
I didn't have to launch into safe mode in order to avoid the problem.
It is sufficient to disable the "VSCommands 2010" extension.

The attached configuration causes the problem to arise.
Posted by Microsoft on 2/2/2012 at 6:12 PM
Hi DRFGHDE,

Thanks for your quick response. To disable all extensions, you may need to launch Visual Stdio in safe mode by "devenv.exe /safemode".
If this issue goes away in safe mode, please help to capture your plugin info. To do this, you can launch an instance of Visual Studio in normal, select "Help"-->"About Microsoft Visual Studio", hit "Copy Info" and paste it into a text file, then send a copy of the text file to us.

If you have any result please feel free to let us know. In the mean time, we will anaylze the newest dump file. And if there is any progress, we will update you.
Posted by Frank Heimes on 2/1/2012 at 9:10 AM
1) Opened VS2010 and attached VS2010 (as Admin) as debugger to it.
2) Opened a solution.
After enumerating all projects beeing loaded, the following exception occurred:

An exception of type 'System.NotImplementedException' occurred in Microsoft.VisualStudio.Project.VisualC.VCProjectEngine.dll and wasn't handled before a managed/native boundary
Additional information: The method or property "VCFilter::get_UrlBehavior" is deprecated and no longer implemented.

This exception was hit indefinately often, so eventually I had to kill the debuggee.
The call stack indicated that VA_X.dll was involved in that particular problem.

3) Repeated the steps above and disabled VAssistX using its own menu entry before reopening the solution.
Same behaviour - Same call stack - needed to end the process

4) Disabled VAssistX in Extension Manager. Restarted and repeated steps 1) and 2).
Same behaviour, but different stack (not surprisingly no VA_X.dll)

5) Disabled ALL extensions and repeated steps 1) and 2).
This time, the solution loaded without exception.

After a short while, the following exception occurred:

An exception of type 'System.Runtime.InteropServices.COMException' occurred in Microsoft.VisualStudio.Data.Schema.Package.dll and wasn't handled before a managed/native boundary
Additional information: Unspecified error (Exception from HRESULT: 0x80004005 (E_FAIL))

This reproducibly happened when I attempted to drop down the "Test" menu (not with the other menu items).

I created a dump named "Feedback-716363-NoExtensions.zip"

Finally, when closing the debuggee, it caused a NullReferenceException in "msenv.dll!CVShell::get_MainWindow() + 0x65 bytes"

Resume:
I ripped out all extensions that might be causing trouble and crashes in order to get VS2010 running at all (while being debugged).
And even with a "bare" VS2010, the debugger pops up reporting exceptions.
So I can't even get to the point I originally intended to examine.

Shouldn't I better spent my effort for testing the VS2011-CTP with my projects, instead?


The file, Feedback-716363-NoExtensions.zip, was uploaded successfully.
Send Files - Standard File Name : Feedback-716363-NoExtensions.zip
Start Time : Wed, 1 Feb 2012 16:54:36 UTC
End Time : Wed,1 Feb 2012 16:59:18 UTC
Time Taken : 282 seconds
Posted by Frank Heimes on 1/31/2012 at 6:27 AM
Hi,

I already knew the procedure you propose in steps 1 through 9 and that was actually the first thing I tried.
Unfortunately, the second instance of VS hung when attempting to attach to the mal-functioning VS process.

I captured the dump files using Marks famous Process Explorer tool.
However, I forgot to explicitly run the 32 bit version - my apologies.
This may not be possible, though, as the tool silently respawns its embedded 64 bit sibling.

I'll try to produce another dump the next time, VS crashes.
Posted by Microsoft on 1/30/2012 at 11:09 PM
Hi DRFGHDE,

Did you capture the later two dump files Feedback-716363-Crash2.zip and Feedback-716363-DeadLock.zip with Task Manager?
Actually, dumps saved using Task Manager never work on 64-bit machines.

Could you please help to capture some new dumps?

You can use the following steps to capture dump file:
1. Start Visual Studio.
2. Start another instance of VS.
3. In the second instance click Tools | Attach to Process...
4. In the list of processes locate devenv.exe.
5. Click Select... and explicitly choose 'Native' and 'Managed' code.
6. Click OK and OK to close Select dialog and Attach to Process dialog.
7. Go back to the first instance of VS and repro the crash\hang.
8. Upon the crash, control should go to the second instance of VS. For hang issue, you may need to go back to the second instance of VS manually, and hit "Break All"
9. In the second instance click Debug | Save Dump As Minidump with heap.

If you are running the VB profile you will not see the Save Dump As menu item. To add this menu item:
a. Select Tools -> Customize
b. Select the Commands tab
c. Select Debug from the Menu bar dropdown
d. Click Add Command...
e. Select Debug from the Categories list.
f. Find the Save Dump As entry in the Commands window.
g. Click OK (the Save Dump As... command is added to the top of the Debug menu).
h. Click Close

You can get detailed steps about how to get the dump file and call stack at http://blogs.msdn.com/debugger/archive/2009/12/30/what-is-a-dump-and-how-do-i-create-one.aspx

The workspaces are still working for you, but please note, the file name should contain the Feedback ID 716363, and you can't upload files with duplicate name to the same workspace.

Thanks again for your efforts and we look forward to hearing from you.
Posted by Frank Heimes on 1/19/2012 at 11:20 PM
I had both extension installed: "Visual Assist" and "VSCommands".
Some features, e.g. syntax highlighting, is implemented by both extensions, so they might obstruct each other.

From Monday to Wednesday, I disabled the VSCommands extension, and kept Visual Assist enabled.
No dead locks or crashes occurred.

On Thursday, I swapped this. Now VSCommand was enabled and Visual Assist disabled.
Within hours, I faced three crashes and dead locks.

I was able to create two process dumps. The dead lock occurred after I had the document windows spreaded out
on two monitors and edited something. The IDE froze and did not process any events anymore.
Eventually, each click on the window just caused a "beep".
I uploaded the dump files as Feedback-716363-Crash2.zip and Feedback-716363-DeadLock.zip, resp.

The file, Feedback-716363-Crash2.zip, was uploaded successfully.

Send Files - Standard File Name : Feedback-716363-Crash2.zip
Start Time : Thu, 19 Jan 2012 23:22:27 UTC
End Time : Fri,20 Jan 2012 00:07:14 UTC
Time Taken : -83713 seconds (Midnight wrap around not handled!)

The file, Feedback-716363-DeadLock.zip, was uploaded successfully.

Send Files - Standard File Name : Feedback-716363-DeadLock.zip
Start Time : Fri, 20 Jan 2012 00:07:56 UTC
End Time : Fri,20 Jan 2012 00:58:25 UTC
Time Taken : 3029 seconds
Posted by Microsoft on 1/17/2012 at 11:41 AM
Hi,

Thanks for the feedback. From the call stack it appears you have Visual Assist Extension installed and that is likely causing the issue. Could you try repro without Visual Assist installed? It would be very helpful if you could provide a new call stack/crash dump file if the issue does repro with Visual Assist uninstalled.

Thanks!
Radhika Tadinada
Program Manager
Visual Studio Platform
Posted by Frank Heimes on 1/13/2012 at 3:38 PM
This time I uploaded to https://sftemea.one.microsoft.com/Upload.uplx?progressid=9
and this time, I received a receipt:

The file, Feedback-716363.zip, was uploaded successfully.

Send Files - Standard File Name : Feedback-716363.zip
Start Time : Fri, 13 Jan 2012 21:04:21 UTC
End Time : Fri,13 Jan 2012 21:51:08 UTC
Time Taken : 2807 seconds
Posted by Microsoft on 1/13/2012 at 12:23 AM
Hi DREGHDE,

Thanks for your efforts. Unfortunately, I can't find any attachment during this site.

Could you please help to upload it once again?

You can try the following two workspace, to solve the pain slow problem, just choose the workspace whose location is much closer to you:

Location: North America
https://sftus.one.microsoft.com/choosetransfer.aspx?key=36a66a19-9091-4152-a7d1-9a59f92fcf36
Password: b^R*P@Xn^Y

Location: EMEA(Europe, Middle East and Africa)
https://sftemea.one.microsoft.com/choosetransfer.aspx?key=1dbb6a7d-772a-479d-ba05-9b9db8b9dd99
Password: {8_4d6ooxW-NJZ

If you have encountered any problem, please feel free to let we know.

Thanks again for your efforts and we look forward to hearing from you.
Posted by Frank Heimes on 1/11/2012 at 2:23 PM
I deactivated the "VSCommands" Extension from DPStudio two days ago to narrow down possible causes of the problem.
Since then I did not face another crash and the number of GUI stalls decreased noticably.

I also noted lots of unhandled managed exceptions in the output pane of VSCommands and that the DPStudio forum is full of reports about these (http://getsatisfaction.com/dpstudio/). So I suspect that this extension destabilized VS2010 and that it did too much work on the GUI thread.

You may want to examine how VSCommands corrupted VS2010 (if it did), how to make VS2010 more robust against bugs in extensions, and how to avert taking the blame for other peoples faults.
Posted by Frank Heimes on 1/11/2012 at 2:09 PM
This time I tried "Standard transfer": Transfer started at 22 KB/sec and eventually "boosted" to 24 KB/sec. About three hours later (about 80%), the transfer aborted and the explorer window reported "cannot display this page".

I tried "Express" and "Resume" again - "Connecting ..." showed up at a stunning 2083 KB/sec and then stalled without any progress.

I then tried to use the 64 bit IExplorer. The later failed probably because sftasia cannot recognize a 64 bit process and attempted to install a 32 bit ActiveX control.

I copied the file to another PC with direct Internet Access (without Company FireWall), adjusted security settings as requested and attempted "Express Transfer". It failed with "Could not install ActiveX component". I restarted IExporer as Admin and retried. This time install worked and upload started - "Connecting ..." showed up but uploading did not start until I went to bed.

So I added the file as appendix to this element, since it is less than 500 MB. This transfer proceeded at about 100 KB/sec and eventually reported success.

Don't be surprised if people don't bother uploading a dump file more than once!
Posted by Microsoft on 1/10/2012 at 11:57 PM
Hi DRFGHDE,

Unfortunately, I can't find the dump file during this site, nor can I find it in the workspace.

Could you please help to upload it once again? If you encounter any problem during uploading your files, please feel free to let me know.

It would be greatly appreciated if you could provide us this information as quickly as possible.

Thank you
Posted by Frank Heimes on 1/9/2012 at 6:46 AM
I uploaded the dump file as requested.
Posted by MS-Moderator09 [Feedback Moderator] on 1/4/2012 at 2:04 AM
Thank you for reporting this issue.

To investigate crash issues, crash dump files are needed.

Please package your dump files into a zip file and name the zipped file Feedback-716363.zip.
You can upload the file to workspace:

https://sftasia.one.microsoft.com/choosetransfer.aspx?key=5d606cdd-4289-47af-bd1d-6ab77876dfe7
Password: @tlZ3+cda

It would be greatly appreciated if you could provide us this information as quickly as possible.

Thank you
Posted by MS-Moderator01 on 1/3/2012 at 7:41 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Sign in to post a workaround.
File Name Submitted By Submitted On File Size  
VSConfiguration.txt 2/6/2012 6 KB