Bug Reporting

[SPerman]

I'm curious how frequently you guys report bugs, either to your VAR or here on the forum. I have a handful that I deal with regularly, and then the oddballs that crop up from time to time. I used to try and report these to my old VAR, but that usually ended up creating more work for me without giving me any more resolution than "its been reported." More often I think of coming here to document the bugs, but that usually ends with "I'll do it when I have a little more free time" which never seems to happen.

[AlexLachance]

I'm curious how frequently you guys report bugs, either to your VAR or here on the forum. I have a handful that I deal with regularly, and then the oddballs that crop up from time to time. I used to try and report these to my old VAR, but that usually ended up creating more work for me without giving me any more resolution than "its been reported." More often I think of coming here to document the bugs, but that usually ends with "I'll do it when I have a little more free time" which never seems to happen.

When we kept up to date, I could report about 3 to 10 bugs a month or so, but since we've been on 2019 and stayed there, I stopped reporting the bugs because I figured they barely kept up when I was reporting the bugs about current versions, they're definetly not gonna keep up with bugs from previous versions.

Since moving to 2019, I've been only reporting the major ones that I needed a fix for, or wanted to keep up with, because I noticed the minor ones are generally issues that have been badly categorized or vaguely specific and end up dwelling in the basement because the SPR concerns only one client in their eyes when in reality there's about 25 SPR's relating to the same thing for 50 clients, they just haven't all been associated together because it seems noone has ever overseen the SPR system.

[Glenn Schroeder]

I report the ones that cause me problems, and have had fair luck getting them resolved.

[AlexB]

I report the ones that cause me problems, and have had fair luck getting them resolved.

I also report these. Most of the time they respond with an existing SPR number but I can only assume it adds visibility to their team when multiple customers are attached to an SPR. We usually run a year or two behind the current release in order to maintain stability but I've caught stuff (mainly API oddities) that haven't been reported.

[berg_lauritz]

Reporting bugs is very tedious and I really tried this year for the first time. Especially when it comes to PDM bugs. After talking several times about the bug (videos, pictures, text) I have to do this:

1. A complete Rx with a video recording showing how to reproduce the issue (Rx Problem Capture Tool – Hawk Ridge Systems Support).
2. A copy of the file vault database (EPDM: Backup and Restore – Hawk Ridge Systems Support).
3. Archives for the file used in the Rx and Plugins folder (under the '0' hexadecimal archives location). These are generally found in C:\Program Files\SOLIDWORKS Corp\SOLIDWORKS PDM\Data\(vault name). If you are uncertain where the file vault archives are stored, view the registry key: HKEY_LOCAL_MACHINE\SOFTWARE\SolidWorks\Applications\PDMWorks Enterprise\ ArchiveServer\Vaults\vaultname\ArchiveTable.

(For the interested: Make a checkmark box on the datacard or a part in PDM. Now open the datacard of the part from an assembly. Regardless of what your settings are - PDM will always jump to the configuration specific tab (let us call it TAB A for this example) in the datacard. Now switch to the @ tab and change something and save the datacard. Now PDM will not only set the variables that you changed on the @ tab - no(!), it will ALSO set the default value of the checkmark box on the configuration specific tab (or ANY TAB YOU SHOWED IN THE PROCESS!). This happens ONLY with checkmark boxes!
I sent them videos AND explained what happened AND added pictures. It would take them maybe 30 minutes to set it up themselves to see the problem but they require ME to send them something?????? AFTER WE PAY THEM SO GENEROUSLY??
Anyways...)

This takes hours and multiple people (IT, PDM admin, approval by manager) to report it and I think it is an audacity that I have to use my time to do all that although we pay a VAR for support! Every time I think about this I am getting too angry to write a proper response.

One bug i.e. was only labeled as an "enhancement request" (ER) and that did it for me. It seemed to me that this bug was not impactful enough so they simply labeled it as an ER instead of an SPR. Great, thanks!

In short: I am thinking of suggesting to get no VAR support as a subscription but only if we really need it.

Edit: spelling

[dave.laban]

I report anything that I find, even if it's not easily reproducible.

[AlexLachance]

This takes hours and multiple people (IT, PDM admin, approval by manager) to report it and I think it is an audacity that I have to use my time to do all that although we pay a VAR for support! Every time I think about this I am getting too angry to write a proper response.

One bug i.e. was only labeled as an "enhancement request" (ER) and that did it for me. It seemed to me that this bug was not impactful enough so they simply labeled it as an ER instead of an SPR. Great, thanks!

And that is exactly why I stopped sending them in too. Paying for something and ending up having to put in so much effort for little to no benefit most of the time. Also because the method of "The messenger" is not a great method in trouble shooting because just about everything can be subjective to interpretation.

[JSculley]

I reported the same SW/EPDM API bug 4 separate times, since SW 2017. Only my latest report (submitted on June 13) has gotten any traction, after I spent days whittling my example code down to 86 lines, submitting it with a sample vault, test files add-in DLL and source code. My reseller tossed all that and made a macro that supposedly exhibited the same behavior and the latest news (as of August 18) is that SW has been able to reproduce the behavior and has generated an SPR. Two month to get this far. At this rate, it won't be fixed until SW 2025, at which point we will have paid maintenance for 7 versions (35 if you count service packs as versions) of SW we've never used because of this bug.

My expectations are low, simply because my carefully crafted example was immediately trash-canned and replaced with a macro that I didn't write.

This is for a bug that hard crashes SOLIDWORKS with an access violation. You would think that would make it a high priority. Imagine how long the process is for some minor thing.

[AlexB]

...
This is for a bug that hard crashes SOLIDWORKS with an access violation. You would think that would make it a high priority. Imagine how long the process is for some minor thing.

If you don't mind my asking, what bug is this? I'm very curious now

[RichGergely]

My VAR is unlikely to report bugs unless you really bug them!

Here is how it goes -
Ring up with a problem
Yes it's a problem
Are you going to raise a SPR
No you can do that

Or even better

Ring up with a problem
Yes it's a problem
Are you going to raise a SPR
Yes we will do
They never raise the SPR

Nothing like paying for maintenance is there.

[JSculley]

If you don't mind my asking, what bug is this? I'm very curious now

Here's the e-mail I sent in my most recent report:

===========================================================
Since as far back as SW 2015, I have been able to induce a hard crash (access violation) in SOLIDWORKS from a simple PDM add-in. I have reported this multiple times in the past,

SR 1-11432121474
SR 1-9635807691
SR 1-23191178626


and it was assigned SPR 1199829 and SPR 967430 both of which are listed as Closed and/or Implemented.

The problem is still present in SW2022 SP2. I have (once again) spent significant time creating an extremely small and simple example add-in that exhibits the behavior. It is only 86 lines of code. It crashes SW most of the time. Occasionally, it will not crash.

I need someone to determine the cause of the crash. If my add-in is violating some unwritten rule about PDM add-ins (which I don’t think it is) I need to know. If this is a bug in the SW or PDM API, it needs to be fixed. This problem has been one of the main reasons we have not upgraded beyond SW2017 and it is becoming increasingly painful to be so far behind in SW releases.

I’ve attached 3 files.

EPDMCrash-2022.cex – The vault export file containing the test workflow and test data card
EPDMCrash-Test Files.zip – the sample directories and files.
EpdmCrash-Code.zip – The Visual Studio Project containing the add-in source code.

The test file zip should be extracted to a folder named ‘Admin’ at the root level of the vault. It contains a directory named EPDMCrash with two subdirectories: (bardir and foodir). The foodir folder contains a single drawing foo.SLDDRW. The bardir folder contains a single model file bar.sldprt

The workflow looks like this:

There are no transition conditions or actions.

The Visual Studio project should be built, and the Debug tab of the project properties should be set to start an external program, and the external program should be set to SOLIDWORKS. Install the add-in as a debug add-in from the PDM Administration app.

To perform the test, run the project in Debug mode. When SOLIDWORKS opens, open the drawing foo.SLDDRW. Then open the part file bar.sldprt. Go back to the drawing, and from the PDM add-in task pane, select the part file (and only the part) and use the Change State button to initiate the Start transition.

Here is what is supposed to happen:

1. The drawing is closed.
2. The model file is renamed and moved
3. The drawing is reopened, pointing at the renamed and moved file.
4. The model file returns to ‘State A’

Behind the scenes it is a little more complicated.

The addin in waits for files entering the Automatic Processing state. When a file enters that state, the addin stores the file ID and folder ID of the selected file for later use. It then gets the ModelDoc2 object for the foo.slddrw drawing file using the path to the file (see line 40 in the code). The addin then calls CloseAndReopen (line 43) to initiate the closing and reopening of the drawing. Per the API docs, calling this method will fire a FileCloseNotify event so that any work that needs to be performed can be done while the file is closed. A FileCloseNotify even handler is added in line 41.

When the FileCloseNotify event happens, the processModel method is called. This method first gets the ModelDoc2 object for the model file for the stored file ID (the file that was selected for the state change). The addin then calls ForceReleaseLocks (line 58) on the ModelDoc object. Next, the addin renames the file from bar.sldprt to foo.sldprt (or vice versa). Then, the file is moved from the bardir directory to the foodir directory (or vice versa). Next, ReloadOrReplace (line 72) is called with the new path to the part file. Finally, SetPromptFilename2 is called (line 73) with the same path that was passed in to the processModel method.


As soon as the processModel method returns control to the CloseAndReopen method, something goes wrong, and the crash occurs:

I’m pretty certain that this is all being done according to the example code that was available in the old SW forums. By the way, those samples are nowhere to be found and the API docs no longer point to a valid link so the examples appear to have vanished.

I’ve run this test about 500 times, just with SW2022. It fails over and over, and then every now and then it succeeds. I really think SW has a serious problem in their API and they have failed repeatedly to find the cause. I can’t make the add-in any simpler.

[AlexB]

Here's the e-mail I sent in my most recent report...

That's definitely a lot of work. I'll take a look at the files when I have free time to spin up a testing vault.

I know I've run into issues with both automatic transitions in pdm add-ins as well as the closeandreopen function with the SW API so I'm curious to see first-hand what's going on. Thanks for putting this together.

[AlexB]

@JSculley I am able to reproduce your issue consistently in my test vault. I tried a few things to see what was causing the issue and it has to do with moving a file in the vault. I'm guessing that since the file is still "loaded in memory" during the close&reopen process that it's trying to look for the file where it last "saw" it in memory, but since it moved it's looking in the wrong memory location.

This is a very strange issue indeed.

[Frederick_Law]

Add a "refresh" to update memory/cache after file move?

[AlexLachance]

The workflow looks like this:


There are no transition conditions or actions.

Excuse me, I might be mispeaking but is that not a circular reference..?

Circular references cause all kind of weird errors in SolidWorks, so I'd guess that doing a circular reference in your programmation would cause issue..?

[AlexLachance]

Here's how I see it, in SolidWorks talk;

I see State A and State B as files.
You have State A open, you save as copy and it becomes State B.
While State A is still open, you take State B and try to overwrite State A, authorisation denied, someone currently has access to it.

So in order for it to work, you have to add some sort of process into it that flushes State A from the "memory" so that State B can then become State A.

[JSculley]

Here's how I see it, in SolidWorks talk;

I see State A and State B as files.
You have State A open, you save as copy and it becomes State B.
While State A is still open, you take State B and try to overwrite State A, authorisation denied, someone currently has access to it.

So in order for it to work, you have to add some sort of process into it that flushes State A from the "memory" so that State B can then become State A.

Nope. It's one file. It starts in state A and ends in State B. In between it is being renamed and moved but API calls are being used which are supposed to detach the file from the file system and allow it to be manipulated (renamed, moved, etc). The API calls do not work as advertised.

[AlexLachance]

Nope. It's one file. It starts in state A and ends in State B. In between it is being renamed and moved but API calls are being used which are supposed to detach the file from the file system and allow it to be manipulated (renamed, moved, etc). The API calls do not work as advertised.

Then you need to work around them. I don't know if it's possible, but I'd suggest looking into how CustomTools does their "Save as", "Save as Copy" and "Rename and move" commands.

I understand that it's one file, but in SolidWorks lingo, it isn't. There are times when the file is not released from memory and I don't know what causes it to sometimes release and most times not, but it's most likely what is occuring here.

Not surprising that SolidWorks advertises something that doesn't work, pretty typical actually.

[JSculley]

Then you need to work around them. I don't know if it's possible, but I'd suggest looking into how CustomTools does their "Save as", "Save as Copy" and "Rename and move" commands.

I understand that it's one file, but in SolidWorks lingo, it isn't. There are times when the file is not released from memory and I don't know what causes it to sometimes release and most times not, but it's most likely what is occuring here.

Not surprising that SolidWorks advertises something that doesn't work, pretty typical actually.

I've reported and worked around it since SW 2015. The workarounds are all fragile and SLOW. Essentially, you have to completely close and reopen the files and replace the files temporarily in any other open assemblies that reference it For large assemblies and their drawings, this increases the chances of lockups and crashes. If a lockup or crash occurs, users are left with a mess, which I of course have to clean up. Time for SW to fix their sh**.

[AlexLachance]

Time for SW to fix their sh**.

I understand and fully agree with that statement but that's not going to change the situation.

The workarounds are all fragile and SLOW. Essentially, you have to completely close and reopen the files and replace the files temporarily in any other open assemblies that reference it For large assemblies and their drawings, this increases the chances of lockups and crashes.

What CustomTools does is essentially what it sounds like you're trying to do, which is why I was suggesting you look into how their process works, if that is possible. It might give you a hint of a different work-around that could be robust while also being faster.

[Frederick_Law]

Nope. It's one file. It starts in state A and ends in State B. In between it is being renamed and moved but API calls are being used which are supposed to detach the file from the file system and allow it to be manipulated (renamed, moved, etc). The API calls do not work as advertised.

Yes, broken API.
Can you add code to check if the file is "released"?
If not, "release" it again?
Any other way to "release" the file?

Even MS release some problematic GC code and later tell everyone not to use it.

Code is dumb, developer is not.

[KQuigley]

Here’s the thing. We don’t report bugs. I don’t see it as my job or my team’s job to waste their time filling out bug reports if a format that suits the software vendor. This applies to all mainstream software not just Solidworks. 99% of the time we work around the issue by asking each other/googling. That 1% is when we contact the VAR and they then escalate it to the vendor. Thats part of their job.
The only time I fill in bug reports in a form vendors want (like using a specific web form, or video or whatever) is when there is something in it for us-discounts/payment/or free software.
I used to be keen on helping out but frankly the goalposts moved too many times and it’s just not worth my time these days. The gus I do help are the specialist add on folks, or start ups. Not the billion dollar corporates.

[bnemec]

Here’s the thing. We don’t report bugs. I don’t see it as my job or my team’s job to waste their time filling out bug reports if a format that suits the software vendor. This applies to all mainstream software not just Solidworks. 99% of the time we work around the issue by asking each other/googling. That 1% is when we contact the VAR and they then escalate it to the vendor. Thats part of their job.
The only time I fill in bug reports in a form vendors want (like using a specific web form, or video or whatever) is when there is something in it for us-discounts/payment/or free software.
I used to be keen on helping out but frankly the goalposts moved too many times and it’s just not worth my time these days. The gus I do help are the specialist add on folks, or start ups. Not the billion dollar corporates.

Exactly!

These companies have managed to get paying customers of a "professional" product to help them debug it, through a terribly tedious process that only helps the seller, and the customers think that it's their duty to do so. That's like hiring a cut rate contractor to put a deck on your house but it's your job to figure out all the things they did wrong, and then convince them it's wrong AND prove to them how those mistakes are causing you harm.

If you want to help the community by testing software and helping identify and solve bugs/problems, use open source.

[jcapriotti]

@bnemec @KQuigley I'm going to partially disagree with you guys on this. We have many custom apps developed in house. If the users don't report the bugs, how would I know to fix them? The report must have some detail and steps to reproduce, if they just say it crashed, I have no idea where to start looking. We ask for screenshots, videos, and screen sharing sessions.

That said, the users still don't report in many cases. We have one newer app that was hastily rolled out and I heard "grumblings" from some users about the issues. No tickets in our system (which IT mandates I have to work on anything). I held a group meeting and many issues were documented. Some users were working around the problems or avoided the program altogether (which was causing other issues). Everyone is busy and reporting the problems take time.

For users of other CAD tools, do they have a better way to report problems?

[AlexB]

@jcapriotti We have a couple of in-house developed add-ins/tools that help aid users in their workflow. If they run into anything, they typically grab me (CAD Admin) to show me the error and it usually ends up with the following questions being asked.
- What's the problem file
- What were the steps you were doing prior to the error
- What did the error say

I'll then work to reproduce and debug if possible, otherwise if I don't hear anything then I can't fix anything as you've said. No ticketing system though, users tend to avoid them like the plague.

[SPerman]

For users of other CAD tools, do they have a better way to report problems?

It's been a while, so my memory is fuzzy, but reporting problems in NX seemed a level of magnitude easier. I reported bugs directly to Siemens. There was no reseller in the middle "adding value." The few times I did need to reach out to them, the person on the other end seemed to have more knowledge about the product than I did. I don't find that to be the case with solidworks. (Maybe that's just my VAR.)

[bnemec]

@jcapriotti I mostly agree with your partial disagreement. I think you did a great job of explaining the great value of bug/behavior reporting and tracking to the developer. We beg for feedback, (bad is often more productive than good) on our projects. It's one of the main ways I can improve as a developer. That type of feedback is very important in the lifecycle of any product. This is why I will go out of my way to put together reports or support open source or community packages.

The difference I see is when a customer pays for a product AND support of the product they should not be expected to pay again when reporting. In a specific case we had with SW in the first year, we spent well into the hundreds of hours serving them a reproducible problem pretty much on a silver platter. They still couldn't reproduce on their side, to be honest I'm convinced they just weren't trying regardless of the lip service. I won't go into the details but it was just endless goose chasing circles until the Director of Engineering got involved and brought up damage compensation. Then things finally started moving. Point is, big commercial software companies actively avoid bug reporting (regardless of what they say, actions are louder than words) with multiple layers of firewalling while open source/community and home brew projects beg for and live off feedback. In the past month I've seen a couple dozen PRs tracked and merged in the dev channel mailing lists I subscribe to; those systems procure, process and implement fixes to PRs >very< well.

[Frederick_Law]

True, problem is not reporting. Problem is the report went into a blackhole.

[jcapriotti]

It's been a while, so my memory is fuzzy, but reporting problems in NX seemed a level of magnitude easier. I reported bugs directly to Siemens. There was no reseller in the middle "adding value." The few times I did need to reach out to them, the person on the other end seemed to have more knowledge about the product than I did. I don't find that to be the case with solidworks. (Maybe that's just my VAR.)

I run into this, sometimes the VAR rep is very knowledgeable, sometimes they are reading from a script and don't know what to do off script. The larger the VAR, I can see this getting worse and knowledge transfer is less effective.

We are seeing this as our internal IT teams get out sourced. We've gone from local teams to one ginormous global team. The number of layers has increased where level 1 knows little about the application, then must escalate to level 2 if the problem is no longer basic. If its beyond level 2, then it must escalate to level 3 (me). This is not a good experience for the users where I was level 1, 2, 3 in the past. Level 1 techs on these large global teams also have a high amount of turnover. I suppose this applies to VARs as well.

[TTevolve]

I contacted my VAR about an issue where opening a design table with edit table in new window returns an error. I get back the canned message to do the solidworks RX stuff, make the video of the issue, and send them the file. I google the error and come across a post that says it's an issue with the latest Microsoft patch for windows 10 and MIcrosoft is coming up with an update.

The thing that makes me mad is why in the world would I waste another 1/2 hour minimum on doing the RX thing and replying to them, when the VAR should be the one looking it up and replying to me that it's a Microsoft issue. It took me less than 2 min to look it up and know what the issue was, and since I can edit in SW it's not a huge issue.

[SPerman]

@bnemec @KQuigley I'm going to partially disagree with you guys on this. We have many custom apps developed in house. If the users don't report the bugs, how would I know to fix them? The report must have some detail and steps to reproduce, if they just say it crashed, I have no idea where to start looking. We ask for screenshots, videos, and screen sharing sessions.

To me there's a huge difference between reporting a bug to an in house developer who cares, and shouting into the void of a large corporation's support portal.

[KQuigley]

I get that @jcapriotti
As I said the last line of my post, we do help the add on guys, the start ups and the open source folks.
But I’m not going to spend an hour writing up a bug, logging it into a billion dollar vendor’s archaic Jira system and then interact with their first line technical folks to talk them through the process. If they pay me I will. If they provide us with free software, I will. Otherwise, we are not a charity.

[Diaval]

... The addin then calls CloseAndReopen (line 43) to initiate the closing and reopening of the drawing.

This is the reason you are still seeing the bug. The CloseAndReopen API has a new version for handling these issues called CloseAndReopen2.

Can you check to see if this works correctly for you when using CloseAndReopen2?

/Diaval

[JSculley]

This is the reason you are still seeing the bug. The CloseAndReopen API has a new version for handling these issues called CloseAndReopen2.

Can you check to see if this works correctly for you when using CloseAndReopen2?

/Diaval

I am well aware of CloseAndReopen2. It makes no difference. My example code uses it and still crashes. Latest word from my VAR is that SW dev is still looking in to the problem. The current cycle is:

1. VAR pings SW for update
2. SW says they are looking into it
3. Wait 1 week
4. Go to step 1

This is week 12 of my latest support submission. Week 348 from the time I first reported it.

[Diaval]

I am well aware of CloseAndReopen2. It makes no difference. My example code uses it and still crashes. Latest word from my VAR is that SW dev is still looking in to the problem. The current cycle is:

1. VAR pings SW for update
2. SW says they are looking into it
3. Wait 1 week
4. Go to step 1

This is week 12 of my latest support submission. Week 348 from the time I first reported it.

Thanks for the update. If I find any workarounds I will let you know.

[Glenn Schroeder]

Here’s the thing. We don’t report bugs. I don’t see it as my job or my team’s job to waste their time filling out bug reports if a format that suits the software vendor. This applies to all mainstream software not just Solidworks. 99% of the time we work around the issue by asking each other/googling. That 1% is when we contact the VAR and they then escalate it to the vendor. Thats part of their job.
The only time I fill in bug reports in a form vendors want (like using a specific web form, or video or whatever) is when there is something in it for us-discounts/payment/or free software.
I used to be keen on helping out but frankly the goalposts moved too many times and it’s just not worth my time these days. The gus I do help are the specialist add on folks, or start ups. Not the billion dollar corporates.

I'll report them in a heartbeat if they're slowing me down. Like this one https://www.cadforum.net/viewtopic.php?p=22736#p22736.

It got fixed, by the way.

[JSculley]

Thanks for the update. If I find any workarounds I will let you know.

There is no workaround. SW support has reported back to my VAR as follows:

=======================================================
"I have confirmed with the SR owner that the new SPR 1239773 is different from the previous SPRs that have been raised by similar code. The SR owner also let me know, after additional troubleshooting with dev, that this particular function of renaming a file and updating the reference path during an event triggered by the CloseAndReopen2 method isn't feasible at this time. Instead they are telling me that the files must be closed for this process to complete successfully.

The new SPR has already been escalated to a higher impact as well, so it should have more influence on future updates. Please let me know if you have any additional questions pertaining to this case or SPR."
=======================================================

So, if anyone is feeling generous, go vote for this SPR and maybe it will be fixed before I retire. I'll be busy putting the horrific kludge back into my add-in code where I completely close and re-open files I need to process and also temporarily replace them in any open assemblies with a placeholder document and cross my fingers that nothing goes wrong.

[Diaval]

There is no workaround. SW support has reported back to my VAR as follows:

=======================================================
"I have confirmed with the SR owner that the new SPR 1239773 is different from the previous SPRs that have been raised by similar code. The SR owner also let me know, after additional troubleshooting with dev, that this particular function of renaming a file and updating the reference path during an event triggered by the CloseAndReopen2 method isn't feasible at this time. Instead they are telling me that the files must be closed for this process to complete successfully.

The new SPR has already been escalated to a higher impact as well, so it should have more influence on future updates. Please let me know if you have any additional questions pertaining to this case or SPR."
=======================================================

So, if anyone is feeling generous, go vote for this SPR and maybe it will be fixed before I retire. I'll be busy putting the horrific kludge back into my add-in code where I completely close and re-open files I need to process and also temporarily replace them in any open assemblies with a placeholder document and cross my fingers that nothing goes wrong.

Sucks but at least they have confirmed that your issue is not fixed and is actually a bug. Guess that is something at least.