VS2005 crashes on check-in if project is running

If you are having a problem using Fortress, post a message here.

Moderator: SourceGear

Post Reply
hutch619
Posts: 41
Joined: Wed Feb 27, 2008 3:05 pm
Location: Portland Oregon

VS2005 crashes on check-in if project is running

Post by hutch619 » Fri Mar 14, 2008 12:32 pm

In Visual Studio 2005 you are allowed to edit an .rdlc file (MS Report) while your project is actually running. However, if I attempt to check-in the file (while the project is running/debugging) then Visual studio crashes. I don't recall Vault 3.5 having this issue. I am currently running Fortress 1.1.
Last edited by hutch619 on Fri Mar 14, 2008 3:23 pm, edited 1 time in total.

hutch619
Posts: 41
Joined: Wed Feb 27, 2008 3:05 pm
Location: Portland Oregon

Post by hutch619 » Fri Mar 14, 2008 1:08 pm

When VS2005 restarted itself I got the "Object reference not set to an instance of an object." pop up from Fortress Client. The only thing that had loaded was the start page (I have "Show Start Page" set at startup in VS options). l don't know if this is specifically related to my previous VS crash or not. The reason I can't be sure if it relates is because I have been getting this error "Object reference not set to an instance of an object" on a frequent basis ever since I upgraded to Fortress 1.1. I hate that window because of how utterly ambiguous it is. I looked in Event Viewer to see if anything was entered under the Application log but to no avail. Is there some log saved somewhere where I can go to find out more (like a stack trace or something)? If not, then could you at least try and catch some of these exceptions in a trycatch block and give a better description of what/why it threw an exception? Thanks.

lbauer
Posts: 9736
Joined: Tue Dec 16, 2003 1:25 pm
Location: SourceGear

Post by lbauer » Fri Mar 14, 2008 2:58 pm

There may be a problem with Client Side Cache. Try clearing it out. You will want to keep the cachemember_workingfolderassignments, and afterwards perform a Get with the option "Do Not Overwrite/Merge Later."
Linda Bauer
SourceGear
Technical Support Manager

hutch619
Posts: 41
Joined: Wed Feb 27, 2008 3:05 pm
Location: Portland Oregon

Post by hutch619 » Fri Mar 14, 2008 4:53 pm

OK, just so there is no confusion I am going to include screenshots of each step so you can try to reproduce the bug on your end.

Create a new windows form project in VS2005 and add a new RDLC report file to the project. Then add solution to source control.
Image

Next, Run the project from within VS (just a blank form comes up). Now, without stopping the debugger (or closing form which will also stop debugger), go to the report you created and change the background color to red and then try and then try a check-in (project still running). I get the following dialog:
Image

Click "Yes" and then you are prompted by Fortress to enter in comments for Check-in.
Image


After puting in comments and clicking OK I clicked on report again and the following error came up in designer:
Image


Try to stop the debugger now (should still be running). This is where VS crashes for me and I get the following:
Image


Before you choose to send (or not to send) to Microsoft, note that I also have 2 other instances of VS running outside of this one (each of which has its own solutions whos source is mapped to Fortress). OK, now go ahead and inform MS that VS crashed and wait for VS to start back up. After about 20 seconds or so I try to access each of the other 2 instances of VS and I get two separate Fortress Errors:
Image


After hitting OK everything seems to be fine. Please let me know if you are able to reproduce this using the same steps. Thanks!

ian_sg
Posts: 787
Joined: Wed May 04, 2005 10:55 am
Location: SourceGear
Contact:

Post by ian_sg » Tue Mar 18, 2008 9:00 am

I wasn't able to reproduce this. After the check in, the designer showed no error, and Visual Studio never crashed. I never got any object reference errors, either. I tried your steps using Fortress 1.1 on XP and on Vista.

Do you have SP1 for VS 2005 installed? Can you (temporarily) disable the VMWare virtual debugger add-in so we can rule that out?

If you'd be willing to turn on diagnostic logging, reproduce the problem, and send the log, I could probably (at least) identify the source of the object reference errors.
Ian Olsen
SourceGear

hutch619
Posts: 41
Joined: Wed Feb 27, 2008 3:05 pm
Location: Portland Oregon

Post by hutch619 » Tue Mar 18, 2008 1:26 pm

Success! I changed a few things about the environment from which I originally had the problem(s).

Here are the things I changed:
- Was using dual monitors - now only using one
- disabled the VMWare virtual debugger add-in (as Ian suggested)
- only running one instance of VS (as opposed to three)

I then tried to narrow down which variable (or combination of) creates the issue. I was able to recreate the problem but was not able to repeat it a second time. I will continue to try and figure out what the exact scenario is that causes this issue.

ian_sg
Posts: 787
Joined: Wed May 04, 2005 10:55 am
Location: SourceGear
Contact:

Post by ian_sg » Tue Mar 18, 2008 1:28 pm

I'm also running dual monitors, so we can probably rule that out.
Ian Olsen
SourceGear

hutch619
Posts: 41
Joined: Wed Feb 27, 2008 3:05 pm
Location: Portland Oregon

Post by hutch619 » Tue Mar 18, 2008 1:46 pm

I can't figure out for the life of me how to recreate it now! I now have dual monitors going, the VMware add-in, another instance of VS running, and everything is fine now! :shock: I guess it's good that it's gone, but I'd like to know what caused it all in the first place. Oh well, I guess I'll just keep an eye on it and let you know if I find out more. Thanks for you help!

lbauer
Posts: 9736
Joined: Tue Dec 16, 2003 1:25 pm
Location: SourceGear

Post by lbauer » Mon Mar 31, 2008 9:50 am

Let us know if we can be of further assistance.
Linda Bauer
SourceGear
Technical Support Manager

Post Reply