One of our staff found a bug for Schedule editing in Revit 2010 64 bit. If modifying a Schedule (in our case a Door Schedule) and you change a ‘Type Property’ and then go straight to the ‘Close’ button in the Schedule (without changing cells or tabbing or anything), Revit will tell you “this will change all instances of this xxx type” and then if you click ‘OK’, Revit will crash.

Here are the steps to reproduce this issue (keep in mind that we are running Revit 64 bit on Vista 64 bit):

  1. Create a schedule that includes Type Properties that you can directly modify.
  2. Open the schedule.
  3. Modify the Type Property.
  4. Using your mouse, click the ‘x’ or Close button in the top right corner of the schedule window.
  5. Revit will provide you with a dialog box – Click ‘OK’.
  6. Revit crashes.

See if you can reproduce this.It would be wise to Save your project before trying!

I find it quite funny that one of the ‘solutions’ to this problem is…don’t lock your computer (“you can prevent this behavior by not locking the computer when printing or exporting”). Thanks a lot! Revit is now telling us what we can and can’t do people! (Or, more correctly, the Revit support staff are telling us.)

This shows that you must give Revit What Revit Wants – or it will make your computer unresponsive!

Issue
You print or export your project in Revit and lock the computer during the progress to find Revit is unresponsive when later unlocked.

  1. Solution
    This occurs when Direct3D® Hardware Acceleration is enabled and the computer is locked > Ctrl + Alt + Delete > Lock Computer. There are two options to prevent Revit from becoming unresponsive when printing or exporting:
    Disable Hardware Acceleration through Options > Graphics > Graphics Mode. Un-check Use Hardware Acceleration (Direct3D). This will prevent Revit from going unresponsive when the computer is unlocked.
  2. If disabling Hardware Acceleration is not an option, you can prevent this behavior by not locking the computer when printing or exporting.

From http://usa.autodesk.com/adsk/servlet/ps/dl/item?siteID=123112&id=13855078&linkID=9243099&CMP=OTC-RSSSUP01

EDIT May 2012

I recently had this issue after reinstalling graphics drivers and using Revit 2013.  I followed the tip on this Autodesk page to run Revit on the primary Windows monitor – this fixed the problem for me.  You can then drag the Windows 7 toolbar to the secondary monitor if you want max screen real estate on your Primary…

EDIT 3/2011
This issue is still annoying some users.  There is a very comprehensive set of comments over at:

http://do-u-revit.blogspot.com/2009/10/whos-dragging-my-stuff.html

A few different solutions are mentioned at that page.

One of our users experienced a very unusual error today. It seemed to appear randomly (no known cause). But it had happened to him before…

Basically, when any object was selected in Revit, Revit would interpret this as a ‘drag’ command, and the object would be moved upward by a certain amount (about 5% of the screen).
We ruled out Direct3D and mouse problems.

However, when logging in as a different user, the problem wasn’t there! So, we reasoned, it must be a user specific setting.

I deleted the UIState.dat file, as Autodesk Support had told me to try this for a different problem. How do you do it? See below quote from Autodesk Support:
To fix the issue, the UI state can be reset to default settings by removing the UIState.dat file by browsing to the appropriate product folder located in one of the following locations:
· For Windows® XP: %USERPROFILE%Local SettingsApplication DataAutodeskRevit
· For Windows Vista®: %LOCALAPPDATA%AutodeskRevit

However, this DID NOT fix up the click-drag problem.

I then went to the registry:
HKEY_CURRENT_USERSoftwareAutodesk
and exported all of the Revit subtree (for backup purposes).

Following this, I deleted [HKEY_CURRENT_USERSoftwareAutodeskRevit] and all the sub-components.

Amazingly, THIS FIXED the issue!!

I am obviously quite happy with this result. Please use this fix at your own risk.

I logged this error with Autodesk Support:
“…Sometimes Revit 2010 x64 running on my Vista 64 bit machine will not load at all – the program stalls with ‘SecSplashWnd’ showing in the taskbar…”

And they replied with the following:
“…There are similar issues logged with the support team.A damaged Microsoft .NET Framework can cause this error. Updating to the latest version of .NET won’t remove the damaged version from the system.
Please make sure that you are installing the program when you are logged in as the local administrator of the machine, and that all the other programs are closed, including antivirus, firewall, etc.
1. Download and save the .NET Framework 3.5 installers from the following link:
http://www.microsoft.com/downloads/details.aspx?FamilyID=6c095bba-6100-4ec9-9c54-6450b0212565&DisplayLang=en
2. Download and save the .NET Framework 3.5 Service Pack 1 installer from the following link:http://www.microsoft.com/downloads/details.aspx?familyid=AB99342F-5D1A-413D-8319-81DA479AB0D7&displaylang=enPLEASE NOTE: the next two steps will remove ALL instances of the .NET Framework from your system. If you are using any software encryption or logon technologies that require the .NET Framework to operate, they will not operate until you have installed another instance of the .NET Framework.
3. Download and run the .NET Framework cleanup utility from the following link. Select all versions and click Cleanup Now.
http://astebner.sts.winisp.net/Tools/dotnetfx_cleanup_tool.zip
4. Install .NET Framework and the Service Pack that you previously downloaded.
5. Restart your system.
6. Once the system has restarted, repair Revit using Add or Remove Programs.Once you’ve updated the .NET Framework and repaired AutoCAD, try launching the application.
I recommend that you uninstall and reinstall .Net in Windows safe mode:
http://usa.autodesk.com/getdoc/id=TS75218 Clean installation on Windows® XP…” (bold mine)

As you can see, .NET needs to be fixed to correct this error. I haven’t yet attempted this fix, as the problem goes away for me after a reboot – if it continues to be a problem, I will have a go at the steps described.

Let me know if this helped you.

NOTE: The .NET Cleanup Tool link doesn’t appear to work – go to this site to find it.

I had a persistent crash when ‘tearing an item off’ the Ribbon, so I logged a Support Request.

The following admission from the Autodesk Support Team representative is quite telling:
“So far we have seen some issue with the ribbon performance. The ribbon performance issue has already been logged with the development team and they are trying to address this issue on the web update. “


Well I hope they ‘succeed’ and don’t just ‘try’! The reply from Support also included a number of steps to try and fix the issue – but I think I might just wait for the Web Update.

One interesting tip from the representative was:
“Disable or Reduce Tooltip Assistance
Set “Options”, “General”, “Tooltip Assistance” to “Minimal” or “None” to increase performance.”

Give it a go – see if it revs up your Revit 2010.

So, you try and print a view with an image in it, and Revit 2010 just decides to crash…and you can’t figure it out!

Well, Revit wants you to choose ‘Raster’ instead of ‘Vector’ under the ‘Print’ dialog – ‘Setup’ button…

There you go, no more crashing!

I have reported this to Autodesk (see below 😉

Summary: Printing ‘linked view’ with image – crashes
Description: When printing a host view with a linked RVT view that contains a high res image.

The same problem occurs if printing the drawing from the linked file (the image seems to crash revit).

However, changing the print type to ‘raster’ solves the problem. Revit should realise that ‘vector’ is going to crash, and switch to ‘raster’ automatically.

Please correct this problem as it is irritating.