Try to convince your manager or whoever came up with that task that it is not a good idea to write end user documentation for software that is in such a shabby state. It will even increase technical debt because you create another document that is going to have gaps and contain errors from the beginning and that needs to be kept up to date with the software.
In the long run it will be cheaper to document the requirements of the software first, define test cases, implement automated tests and refactor where it makes sense. With reasonable requirements and change management it will be much easier to write end user documentation and keep it in sync with the software.
If this is not an option, talk with some key users and find out how they are using the software, document their use cases, add some diagrams showing the main modules of the software as far as it is obvious, paste in some screenshots, explain input and output files as good as you can. You will end up with a document that at least looks like a user guide and might even be somewhat useful for a limited period of time. But make sure that you are not the person that will be responsible for maintaining the document.
In some cases this really is the best option because end user documentation has a very low priority from a business point of view in many software projects. This is because it tends to have little influence on project success.