2 Replies Latest reply on Apr 20, 2016 11:45 AM by John Alexander

    Solidworks Crash During Macro Execution

    John Alexander

      I'm having trouble tracking down the cause of this crash.

      The crash happens consistently when using a macro that I wrote for ballooning assembly drawings. The macro registers an even listener that intercepts selection events, grabs a reference to the selected component and inserts a balloon (sketch block instance) in a pre-defined location. It then performs a sequence of updates on the sketch block's attributes. This process normally works without problems - the crash occurs when the user attempts to do something immediately after the sketch block is inserted.


      After insertion, the user still has control - if they move the balloon in the split second (or longer) that the macro is interacting with the balloon, it will crash.

      Some methods/properties that the macro calls after creating the sketch block instance (in the period when the user is capable of causing a crash) are:

      InstancePosition, IGetAttributes, IGetLeaderPoints, SetAttributeValue, SetLeader, Definition, Name


      I'm suspicious that the problem has to do with manipulating the sketch block leader or the sketch block position while the user is dragging it around but I'm not sure how to prevent that from happening. Ideally, I would lock the user out of making edits to the active window while the macro performs the update but every method that I have tried has not worked.

      Alternatively, I've thought of testing whether or not the sketchblock is being dragged before attempting to do anything with it; however, I can't seem to find any property or method that would reveal this information.


      My next step will probably be to have the macro write to its own log file to figure out exactly what property access or method it is calling when it crashes.


      I've included an excerpt from the Solidworks dump log below.

      <MINIDUMP> "03a9be8f-9747-4bb5-9f6f-ff35e5aa9831" </MINIDUMP>

      <AD5> auModelDoc_c::XDispatch2::ClearSelection2;auAm_c::JournalWriteNotify;auAm_c::iFireEventV;auDrawingDoc_c::NewSelectionNotify;auModelView_c::RepaintNotify;auModelView_c::GraphicsRenderPostNotify;auModelView_c::RepaintPostNotify;auDrawingDoc_c::ClearSelectionsNotify;auSelMan_c::XDispatch::GetSelectedObjectCount;

      <EXCEPTION> "Access Violation at e8f18b48 (virtual address e8f18b48), attempt to write to memory";

      <RAWSTACK> sldworks:E8F18B48:E8F18B48,mfc90u:690C8201:00268201,slduiu:49DC7B8B:00DC7B8B,mfc90u:68E93579:00033579,mfc90u:68E92CC8:00032CC8,slduiu:4987DC42:0087DC42,slduiu:49DD7A4D:00DD7A4D,slduiu:49EC8A90:00EC8A90,slduiu:49D7399B:00D7399B,slduiu:49DD6862:00DD6862,slduiu:493EC7B9:003EC7B9,slduiu:493B7982:003B7982,slduiu:494A45A2:004A45A2,slduiu:494AFF40:004AFF40,slduiu:494B0CF2:004B0CF2,slduiu:492D1331:002D1331,mfc90u:68E75B1A:00015B1A,mfc90u:68E750B8:000150B8,sldappu:470B08CB:000F08CB,slduiu:495FC55A:005FC55A,mfc90u:68E732F0:000132F0,mfc90u:68E7369D:0001369D,mfc90u:68E7060F:0001060F,USER32:76E89BD1:00019BD1,USER32:76E83BFC:00013BFC,USER32:76E83B78:00013B78,OPENGL32:F394948E:0003948E,USER32:76E89BD1:00019BD1,USER32:76E898DA:000198DA,mfc90u:68ECE1E6:0006E1E6,mfc90u:68ECEAB3:0006EAB3,sldappu:47000722:00040722;




      <MINIDUMP> "9455213a-f6ac-4a00-a383-1aa92cf3bf28" </MINIDUMP>

      <EXCEPTION> "Invalid Deactivation";

      <RAWSTACK> ntdll:76FDF822:0006F822,USER32:76EF117B:0008117B,ntdll:76F88B03:00018B03,ntdll:76F99DAD:00029DAD,ntdll:76F88A4C:00018A4C,kernel32:76D8050E:0003050E,MSVCR90:72A7568D:0005568D,ntdll:76F99D2D:00029D2D,ntdll:76F891CF:000191CF,ntdll:76FC1248:00051248,sldworks:E8F18B48:E8F18B48,mfc90u:690C8201:00268201,slduiu:49DC7B8B:00DC7B8B,mfc90u:68E93579:00033579,mfc90u:68E92CC8:00032CC8,slduiu:4987DC42:0087DC42,slduiu:49DD7A4D:00DD7A4D,slduiu:49EC8A90:00EC8A90,slduiu:49D7399B:00D7399B,slduiu:49DD6862:00DD6862,slduiu:493EC7B9:003EC7B9,slduiu:493B7982:003B7982,slduiu:494A45A2:004A45A2,slduiu:494AFF40:004AFF40,slduiu:494B0CF2:004B0CF2,slduiu:492D1331:002D1331,mfc90u:68E75B1A:00015B1A,mfc90u:68E750B8:000150B8,sldappu:470B08CB:000F08CB,slduiu:495FC55A:005FC55A,mfc90u:68E732F0:000132F0,mfc90u:68E7369D:0001369D;



      <AD2> "UNLOAD_ADDIN" "BendSequenceSwu.dll" "" [0.00] 0

      <PROCMEM> CMD:AppFinish ATTR:PageFileBytes=637296640 ATTR:PageFileBytesPeak=639062016 ATTR:PoolNonpagedBytes=184788 ATTR:PoolPagedBytes=2003704 ATTR:PrivateBytes=637296640 ATTR:VirtualBytes=2423164928 ATTR:VirtualBytesPeak=2429353984 ATTR:WorkingSet=669597696 ATTR:WorkingSetPeak=669782016 ATTR:AvailableReservesMask=7 ATTR:GDIHandlesTotal=10000 ATTR:GDIHandlesUsed=1253 </PROCMEM>

      <MEMORY> 507489, 669782016, 668483584, 2107472, 1987256, 192052, 183948, 635940864, 639062016, 635940864 </MEMORY>




        • Re: Solidworks Crash During Macro Execution
          Artem Taturevych

          Hi John,


          I believe the problem with this method: 2012 SOLIDWORKS API Help - SetAttributeValue Method (ISketchBlockInstance)


          I remember some time ago I was trying to use it and had similar symptoms so I have to avoid using this method and refill the notes by exploding the block and changing the notes directly and then making the block again.




            • Re: Solidworks Crash During Macro Execution
              John Alexander

              Thanks Artem,


              This is sort of old now, but I figured I should follow up for posterity.


              The macro is actually using SetAttribute (2012 SOLIDWORKS API Help - SetAttributeValue Method (ISketchBlockInstance)) quite a bit without problems - there are about 10 attributes in each sketch block "balloon" that get updated periodically. It loads the relevant sketch block instances into memory every time the macro is initialized.


              I have more reason to believe it has to do with using the InstancePosition sketchblock properties while they are being dragged by the user.


              One of my coworkers found a workflow while they were using the macro which prevented the crash. Basically, there are two buttons: one called "create new stack" and the other called "append selections". Both of them register selection event listeners. "Create new stack" stops intercepting selection events after the user clicks a point on the drawing (it creates a new balloon stack and draws a sketchblockinstance at the selected position). The "append selections" listener persists after the first sketchblockinstance is created. While it is active, it intercepts selection events by iterating over all selected objects to check if they are components and then deselecting everything. My theory is that when the user goes to drag a sketch block while that button is toggled "on", the selection event is intercepted before they can drag the balloon. The sort of janky solution was to just turn this "append selections" button on every time "create new stack" is activated.


              I realize that this doesn't conform my suspicion of InstancePosition being the culprit but it doesn't invalidate it either.