How to find a problem in the project that causes crashes?

[WimYogya]

In my past few weeks of intense work with TFP I came across a fatal crash three times.
Fatal means: the program became non-responsive, even hours of waiting didn't help, only exiting the program was possible.
Restarting brought up the same problem - and once a project has become non-responsive, repair will not work either: also that is non-responsive.

So the only solution was to go back in time and find a version that was clean. But which one is that? If you have nine backups, where did the fatal error enter? Is there more to find the proper clean version than just trial and error?
And also: if you want to find the CAUSE of the trouble, what can you do? I have the feeling that 'dirty wall joints' (with leftover bits and pieces from previous manipulations) could be the main cause. True?
Other tips and tricks to find the troublemakers?

In all three cases I managed to go back in time, but every time I lost 6-15 hours of work! And of course I didn't remember all the changes I made since the clean backup that I started to use as the main file. Would be nice if TFP would have a logfile where all activities would be logged, so that you can recreate your changes. But I guess this is too much to expect.
For help me find the changes I did the following: I started the corrupt project file on a separate laptop, so I had two screens next to each other with two different versions of my project. As long as I used the corrupt one for viewing only (not changing anything) there wasn't a problem, even in different cam views etc. But it still took lots of time to do the lost work over.
Any suggestion to make life easier is welcome ;-)

[Draft Patrick]

Probably this is part of the same issue
http://forums.turbofloorplan.com/index.php/topic,2373.0.html

It is not uncommon that crashed files become corrupted files

Pat

[Doug.S]

I know of no other way than as you described....hunt and peck.
Save often especially before you do anything beyond ordinary...such as import.

Also try a small render both basic and advanced now and then....problem objects, not seen, will often show as a failed render....if it renders OK (both ways) then it is probably a non-corrupted safe good file.

[Jack Zimmer]

Hi Wim,

The first thing I look for are bad walls as you say. Next roofs.

You don't say when the crash occurred. I assume because you didn't mention rendering it was in Model space either plan or 3D mode.

What I do is open the file, go to View Manager and turn everything off, that includes the terrain, dimensions, text, everything. Then I save the file with a new name.

Then go back to View Manager and turn on the walls one floor at a time. Each time looking for problems by selecting the walls and inspecting corners, looking for left over parts, odd breaks etc.

A quick render of each floors walls as Doug says, may cause the crash and give you an idea of which floor the problem is on. Once you narrow down the floor location, if you can't see a problem, just delete a whole section of walls at a time. I normally do 1/4 of the plan delete / per floor , then do a rendering and see if I get a crash.

What you don't want to do is save the file while walls are deleted as this prevents the use of undo.

If you delete 1/4 , do a render and do not get a crash, then you can delete another area (as the first delete wasn't the problem). When you do find a problem area, you can then start being a bit more particular about what you delete and test in that 'bad area'.

While I don't get many crashes, when I do, using this method usually finds the problem quite quickly.

If no crash occurs when doing a quick render with walls, move to roofs , having only them turned on.

I'm surprised you had to go back so far to find a good file. Most crashes seem to occur while doing a current operation.

Jack

[Doug.S]

There is one tried true technique for eliminating or finding an offending item.

Delete or hide one half (not as easy to do in TFP but you can be logical and use a practical/logical method)...then render.....if OK then the problem is in the other half; go there and delete or hide 1/2 of that part...check/render....

continue doing elimination by halves until you hit the problem item.

This is "brute force" and time consuming but always works.

[WimYogya]

The solutions described in the two previous posts refer to rendering. I haven't even been so far in the program.
At the moment I am just designing. Rendering comes later.
But if I keep getting crashes (no more, recently, fortunately!) I will use the methods described.
Thanks.

[Allan Chesney]

Hi Wim,

Renders have been mentioned at this point as they sensitive to wall or other corruptions.  You may get away with a corrupt wall join for quite a while but usually a render will fail if there is one.  You can do a render any time - you do not have to finish the design first. In fact it can sometimes help in design and decision making, when you see where the sun will fall in different seasons for example.

Allan