Yes you can, but it will not help you much.
What you need is information on what was happening when an exception was thrown in your code. In many cases, users can't even provide you the information you need, because they have no idea what is going on in the code. In other cases, they do have relevant information (e.g. what they were clicking when the error occurred), but 1) it is not their job to provide it, 2) it is very hard for them to do so (they have no idea of programming, so it is very hard for them to recognize which parts of their knowledge are relevant for you, and to find a formulation useful for you), and 3) your buggy application just interrupted their work flow with an error message. You violated their expectations and wasted their time. They are angry, and don't want to lose any more time and spend the high cognitive effort required for writing a meaningful error report for you. You have neither the right nor the technical means to make them do so.
For these reasons, you cannot make user reports the main source of the error context information you need. You can gently nudge the users willing to make error reports into making better quality error reports, but you have to live with the fact that for virtually all errors, you will get no information from the users. In the rare cases where you get a report, it will be a very nice bonus for you. But it is a bonus, and you can't rely on it to become your primary information source.
The first thing you should do, if you are not already doing so, is to implement user-friendly error notifications. There are guidelines for doing so, I generally use the Microsoft guidelines, the general principles in them are applicable across all platforms. You can certainly look around for other sources on how to create good error notifications. One important thing which will happen when you do so is that you will stop showing all unhandled exceptions to users. So, you have to take leave of the idea that the user will help you with all exceptions, he will only be able to help you with the ones you show to him. The rest will have to be logged and handled in some other way, e.g. you can set up a test environment where you can turn on stack traces.
You can certainly decide that, if a user wants to submit an error report, he also has to write an error description. This will mean that you will get very few error reports altogether, but the ones you do get will have a potentially useful description. Most users will still have no idea about the error, and no incentive to describe what they were doing when the error occurred, so they will choose to not write anything. If writing is mandatory for sending a report, they will choose to not send a report at all. I will only go this way if a report without user description is truly worthless.
You cannot make both sending a report and filling in some information mandatory. If you do this, you will anger many users to the point of giving up the use of your product and going to the competition. If they are not allowed to stop using your product (e.g. it is a product they have to use at work and the company management decides which product gets used), they will hate you and your system, give it a general bad reputation, and they will not provide you any usable information, probably starting write or paste nonsense into the mandatory text field. Not only will you have created a bad quality product, you will have to wade through error messages containing jokes, complaints, threats, and maybe even troll messages mimicking a real problem but not at all related to the actual situation in which the problem occurred. Users can be very creative in their destructive behavior when you work against them. There will be some more additional well-meant descriptions, but I doubt that much of them will be actually useful for you.