Are you dropping the object at completion each time?

Yes.

I am calling Cleanup on the SY_Session object

and DropObject on any result from NewObject including SY_Session.

On all of these objects plus the ProvideX.Script, I am calling System.Runtime.InteropServices.Marshal.ReleaseComObject

When the NewObject call to SO_PackingListPrinting_rpt works, I see my pvxcom.exe process appear and go away in the Task Manager, so I believe that it is normally getting cleaned up.

There are no other pvxcom.exe processes running.

It may be that pvxcom.exe is not the real issue, but that the SO_PackingListPrinting_rpt or SO_PackingListPrinting_UI is the source of the issue?  I cannot see what these do without a license for PxPlus (I think).

It seems as if waiting longer between printings reduces the failure rate.  I have now put in a timeout and a retry on the command.  If I retry immediately after a failure, I tend to get another failure.  By adding 5 to 10 seconds, I get a much higher success rate with the second try.  Also if I manually wait 10 seconds between printings, I get a high success rate.

This tells me that something is getting "cleaned up" after the printing is "done".  I put in a forced garbage collection after I dispose of all of the printing objects, session, and ProvideX.Script objects and this doesn't help.  I can also see that pvxcom.exe is gone right after the printing is done.  Could the server have a resource that takes time to clean up?

What version are you running?

I recall having a similar issue with scripts on an earlier version.  Had a button script that ran in sales order entry.   After about five or six uses it would lock up.   If you exited sales order entry before 5/6 uses and came back you would be ok.  Presumable doing that reset something in memory.

I don't specifically remember which version I encountered it,  but the problem went away in the 2016 version.