Community Tip - Did you get an answer that solved your problem? Please mark it as an Accepted Solution so others with the same problem can find the answer easily. X
I have a bug to report on the renderer that exists in Creo 2.0 M050 and persists in M060. It's 100% repeatable and only requires a drawing of sufficient complexity (tested on multiple) to cause a crash-to-desktop (all work lost) condition (which as a programmer, is the worst you can do aside from "corrupts computer"). I can get the crash to happen on all four of our systems (a mix of Dell Precision workstations and Optiplex machines) of which one is on the "certified hardware" list.
The crash is easy to reprodice. Load a drawing of a moderately complex assembly with views in "No hidden line" mode... something that takes a few seconds for the HLR process to run. Next, switch to layers. Then hide a layer such as surfaces. The program should now begin the process of hiding the layer which should take a few seconds. During this time, there is no indication it is working. No "wait" mouse-pointer, no "processing" stop-sign, nothing. If you do nothing while it is processing, it will eventually succeed and you can continue working. If though, while it's processing, you try to click on any layers, or switch back to model tree view, or do anything else while it is in this "processing" stage (it won't let you, the interface is locked), the program will suddenly crash to desktop when it finishes processing the hide request.
Go to the PTC.com home page, click SUpport then 'technical support' in the drop down that appears. On theupper right is 'contact support', click that. Int eh pop up dialog click 'Open a Support Case'.
Or, click here.
You will need an active maintenance contract and your company's SCN number.
When I want to report a bug, why should I pay for a maintenance contract therefore?
The only way to talk to PTC Tech support about a problem you are having with the software is to have active maintenance. With maintenance, you also get the software updates (which is usually how they solve bugs).
You need to make a new post for your question in the Creo Elements Direct forum.
https://community.ptc.com/t5/Creo-Elements-Direct-Modeling/bd-p/creo_elementsdirect
Welcome to the forum, Bryan.
To answer your question, you log a case with customer support. Current maintenance customers have access to case logger. If you are not the administrator, you need to get some information from them (typically the IT group of your organization). They can provide you with the required information to log a case. PTC will get back with you and often require an online session with your to determine the cause of the problem and provide you with either a resolution of they will submit an "SPR" where engineering is notified of the problem.
As for your specific problem, indeed, there has always been a "trip point" in all Pro/E products that can totally stop the software. Drawings seem to be a favorite for this to happened in. Even in the day of single core processors on approved hardware I've had to watch myself on certain commands.
Creo is certainly not alone in this. I was working on SolidWorks at one time and on the very same command, every time, the system would just dump the SW session completely. Nothing more frustrating.
I've also had a specific corrupt file that would let me continue working during the original session. But I could never open it again, neither the original part nor the using assembly or drawing. I had to back-track many versions (luckily saved!) to where I started using textures and images for renderings. The files were totally hosed from the now incorporated image files. It was when it started mixing up images that I should have known there was a problem. My point here is that it could be a corrupt part and only the symptoms are what you are experiencing.
What is not clear from your post is if this is the case with a specific file, or if you can reproduce this on any number of files that have a specific complexity level. I suffered a pretty good performance hit when I went to M030. I tend to agree that background operations should have some sort of indicator that they are busy working.