I think my lisp is causing a fatal error when closing

[Jemauk]

I have lisp that runs an audit on close & exit, and it does what it is suppose to do. But after the drawing has closed I will get a fatal error. The error doesn't happen every time, but a majority of the time. That's why I am not sure if it is the lisp or not. I was wondering if someone could look over my lisp and see if they see something wrong. Or that could make it more efficient, sometimes it does seem to take longer to run than the audits normally does.

Thanks!

Joseph Mauk

C3D 2020

Win10 

(command "undefine" "close")
(command "undefine" "quit")

----------------------------------------------------------------

(defun c:close ()
(setvar "cmdecho" 0)
(command "AUDIT" "Y")
(princ "\nDone! \nAll is good!")
(setvar "cmdecho" 1)
(command ".close")
(princ))

----------------------------------------------------------------

(defun c:quit ()
(setvar "cmdecho" 0)
(command "AUDIT" "Y")
(princ "\nDone! \nAll is good!")
(setvar "cmdecho" 1)
(command ".quit")
(princ))

[Anonymous]

I think it's good !! what she sets out to do !! 😁
You can add * ERROR * treatment but I don't know if it's necessary. 🤔

[ronjonp]

Why do you feel the need to audit a file every time it is closed? Do you have something else running that has been corrupting drawings?

[Jemauk]

Just more for maintenance (since not everyone will do it).  We do use GIS data, quite frequently any more, and the connections seems to leave behind a few errors. Then it start piling up after a few xrefs. So I was wanting it to be more of a preventive measure.

[Jemauk]

Right, I didn't think I would need one either. It happened twice, first thing, this morning. That's why I thought I'd ask for help. Now, it hasn't done it since. I didn't take the time to try and search for the error code, but it was an unhanded access violation. 

[Scottu2]

What happens when the user opens a read only drawing and tries to save it?

[Scottu2]

Another possibility could be caused by the server not releasing the file in a timely manner.  Even after a different user's autocad removes the .dwl lock files because of other high server disk activity.  In my situation our network guy had to reboot the server.   One other item could be proxy graphics or AEC objects not allowing to save the drawing, but this would be a constant error not intermittent. 

[Jemauk]

Hmm idk, I haven't tried just doing a read only version. The fatal error occurs after the drawing closes not, during the command. As soon as the drawing closes it will give me a flash and then the error box. But it only started after I implemented the lisp. My thought was maybe it was messing with a process in the background.  But it hasn't happened in a little over a week now and the lisp is still implemented.

Side note, every time that it would happen I would lose the Support File Paths that I added. Now that problem is still going on but no fatal error...

[Scottu2]

Lost support paths?  All of them or just some?

Are the drawings on a network?

At startup, network support paths are removed when Autocad cannot access the mapped network drive letter.

The local drives are like C: and 😧 are retained.

As noted in the other post, are encountering frequent errors?

Are they errors like missing a vertices due to flattening objects?

[Jemauk]

Just the Support Paths that I have added on our network. The network paths in the working support and trusted locations will still be there.

Yes the drawings are on a network.

It has happened two or three times in a row before, then nothing for a day or two. Now its been a week with no errors.

No, there are no errors in the drawings when I reopen them. It will just be the same fatal error access violation after the drawing closes.