Dear all, i've got a problem with my Inventor Professional 2012. i've got the factory desing ultimate suite for 64 bit.
my pc has got a multiprocessor it's an inter core i5-2540M and 8Gb of ram.
I have to do the drawing of an assembly consisting of 53 pieces, the problem is that these pieces have curved geometries, it's an engine.
When I start to compute the views it runs the InventorViewCompute.exe, and that's right.
if i decide to stop this work and to close the program (all inventor's windows) and i'm going to see the task manager i find that the InventorViewCompute.exe are still computing and if i don't kill those processes,by forcing them, they still working without stopping.
I've read here: http://usa.autodesk.com/adsk/servlet/ps/dl/item?si
I've also have download the sp1 for inventor 2012 and also the one (sp2) for the Factory Design Suite Ultimate 2012.
what can i do to resolve my problem?
Hopefully any of you can help me.
This is the first time we are hearing of this problem (and there is always a first time .
InventorViewCompute.exe is a child process of Inventor.exe and must and should terminate when Inventor.exe is stopped. Its possible that it may be calculating something and may not immediately terminate, but ultimately it should and must as the main processes has exited.
Can you elaborate a little bit on the problem?
1. Did you verify Inventor.exe has gone from task manager?
2. How long did you wait before you had to force kill InventorViewCompute.exe?
3. Are you on Win7 or XP or Vista? Can you post your system resources?
Can you please send us your dataset (IAM, IPT, IDW) so that we can investigate? You can reach me at: sundarsATautodeskDOTcom
I have experienced a related issue. Working with a moderate size idw (3005 occurences, 714 open documents), when the model updates the views recompute and it can take a really long time (1/2 hr). This morning it was looking to do it again but I saved and shut down Inventor. 3 instances of InventorViewCompute.exe were listed in the task manager (possibly corresponding with 3 views that were in progress of updating?) and they were generating ~50 hard faults per second each. It took about 5 minutes for the 3 instances to shut down after Inventor shut down. I did not notice an instance of Inventor.exe at the time but I didn't explicitly look for it either.
After everything shut down, I restarted Inventor 2012 and opened the idw again. 3 views updated within 30 seconds.
OS Name Microsoft Windows 7 Professional
Version 6.1.7601 Service Pack 1 Build 7601
Other OS Description Not Available
OS Manufacturer Microsoft Corporation
System Name xxx
System Manufacturer Dell Inc.
System Model Precision M6400
System Type x64-based PC
Processor Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz, 2535 Mhz, 2 Core(s), 2 Logical Processor(s)
BIOS Version/Date Dell Inc. A07, 11-Aug-2009
SMBIOS Version 2.4
Windows Directory C:\Windows
System Directory C:\Windows\system32
Boot Device \Device\HarddiskVolume1
Locale United States
Hardware Abstraction Layer Version = "6.1.7601.17514"
User Name xxx
Time Zone Eastern Daylight Time
Installed Physical Memory (RAM) 8.00 GB
Total Physical Memory 7.99 GB
Available Physical Memory 3.19 GB
Total Virtual Memory 16.0 GB
Available Virtual Memory 11.0 GB
Page File Space 7.99 GB
Page File C:\pagefile.sys
I had the same problem today. I remembered that my collegue had the same problem and got adviced by some support guy to unclick the "Enable background updates" in Application options/Drawing window (restart computer and open the drawings again). My theory why this "works" is because before i did this all the InventorViewCompute.exe threads was working against pagefile.sys wich ofcourse resides on my harddrive and therefore all threads used very little cpu but a lot of swappings on the harddrive. After disabling the background update it seems to do all in memory instead and therefore much faster. If this is true you should really fix it Autodesk..
InventorViewCompute.exe should behave just like any other windows processes. If you are running low on RAM, then it would indeed go to the pagefile, however, if you have plenty of RAM, it will use available RAM to execute itself until the system starts running low. The process has no control over when to use RAM or pagefile as far as runtime memory goes.
However, the process needs to cache data and may do so either in memory or in the pagefile depending on the data size. Only in rare cases have we seen this to be a bottleneck. It's true that going to the hard drive does become cumbersome.
Those rare cases are when your model might be extremely big or has lots and lots of bodies (threads, composite surfaces, shrinkwrap and /or translated data). For example, just unchecking "thread display" will speed up your drawing views if you have lots and lots of threaded holes.
Thanks and please let me know if you have any further questions.
In short this was not a special assembly (not many threads at all) nor heavy. I guess this might be a rare case. However this is not a reportable "error" so i wonder how many just curse over their "slow computer" and leave it on over the night. So why doesnt the process that updates the views when i disabled the "Enable backround updates" think it should use the pagefile, or atleast does the whole update very much faster.. does that process have better info of available RAM?
Thanks for your questions. I guess I am interested in finding out whether InventorViewCompute.exe is really paging and is hence is slow? We have seen that the process can get slower in those special cases i had mentioned earlier particularly with read/writes. It would be helpful to get the dataset (assy, parts, idw) and analyze it before coming to any meaningful conclusion.
Would it be possible for you to send me your files? You can contact me at sundarsATautodeskDOTcom
If its too big to zip up under 8 MB, I would suggest that you either split the zips or I can setup an ftp site for you.
Im sorry, but I cant send you those files due to restrictions. As i said, there wasnt anything pequliar about the drawing/assembly except(!) that they were earlier versions. So maybe there was some migration business going on?