UPS isn't required for workflows. That being said, what you'll want to do to debug the workflow is attach your Visual Studio instance that has your WF loaded up to the following processes:
- w3wp.exe (the one running the right app pool account; if you're not sure which one it is, just attach to all of them)
- owstimer.exe (there should just be one of those)
It should then hit breakpoints like any other application. Note that depending on what the workflow is doing, it could run from either process (as a general rule, asynchronous activity runs from OWSTimer and synchronous stuff from w3wp) so it's necessary to attach to both.
I also highly recommend making use of your workflow history list: write to it every time a stage has completed and especially whenever it throws an error. For the most part, any error thrown and not caught in your code is just going to cause the workflow to cancel itself with no other record.
That should at least get you started. Otherwise, I have no idea why it's dying, of course, because I can't see what it's doing, but I will say that in my experience the #1 reason why workflows die without errors is that the workflow can only store basic objects like strings and numbers. If you have, for instance, a separate SPList object that you need to access, you can't just make a global SPList variable that gets called over the course of your workflow. You would need to save, for instance, the GUID of the list globally and then call it separately in every separate function you utilize it.