When I hit a really painful real-world problem, sometimes it helps to escape to a land of make-believe where absurd assumptions can be made - and then work backwards from this more pleasant world.
So, let's remodel your problem as one that...well, sucks less to have to deal with.
Let's say you know that the next time this function runs and someone tries to print a label, you will get this duplicate behavior. However, this isn't a perfect world - you can't change the request or use step-through debugging to walk through the problem one line at a time.
So, how will you figure out what caused it this time, when you can't just "do that again" and have it happen again?
In short, logging out stack traces and debug info, identifying the most critical question you need to answer. The most obvious is, at a minimum, what EXACTLY is being sent to the printer? Is the printer being told once to print an item, or is it being told over and over and over, or is it being told once but with a quantity specified?
One "simplest possible thing that might work" is to log exactly every single print request, with the expectation that this might be a big log (deal with that in planning). At the very last step before a request is sent to the printer, log exactly what is being sent. Depending in your implementation this might mean wrapping a streamwriter in a buffer, etc - whatever you need to do).
This log should allow you to "reprint" any label using only the information right there in the log, so you can just "resubmit" the request and have it work EXACTLY like if the request was created by the system in the normal fashion.
Then, the human component - you need someone to make a note of when the bug happens, as close to exactly in time as when it happens (so you can go hunting for a rough timestamp), and even attach one of the duplicate labels to your little "bug report" piece of paper with the time on it. If they could make a note of what came before and what came after, that would be even better - but this is obviously subject to business workflows that may be out of your hand. The suspect label and a rough timestamp would be hugely helpful though.
Then you search your potentially huge log files for that event, and you study it. You resubmit that label and see if it happens with that exact, perfect copy of the request - or if it works normally. You look closely at each byte of the request and make sure it is perfectly according to spec and just like any other proper request.
You make sure that this really is exactly what is being sent to the printer, even if you have to have someone setup a networking appliance as an invisible repeater that logs network traffic so you can make sure it really works like you think it works.
In short, you narrow it down - is it the request to the printer that's bad, or not?
Regardless, you'll learn something from this. Either you learn it's software screwing up the request, or it's "something else". This is defining and limiting the scope of the problem.
Then what? Well, you can always try a different printer, a new computer generating the requests, new network/cable to the printer, etc. Diagnosis by part-swapping is a time-honored tradition in all mechanical fields :)
If all else fails, list this duplicate result as a "rare occurrence, approximately once per month", unable to reliably replicate, known work-around "throw extra labels away", etc...declare it's caused by ghosts, with relevant XKCD:
...and accept that some things are not meant for man to know. Some day the problem will go away, no one will know why, and you get a good story to share with senior programmers some day when "unexplained programming mysteries" becomes the lunch topic.