Report a problem
What is enough to send for a problem to be reproducible — and what you must not attach.
What is enough
Four things make a report workable. None of them asks for your files.
- The session header from the log: three lines giving the version, the operating system, the Java version and the language. They save the most frequent round trip.
- What you were doing, in one sentence: the file you had open, the button you pressed, the transformation you started.
- What you expected at that moment.
- What happened instead, and the message shown word for word if you still have it.
And if you have none of that, write anyway. A vague report can be worked on by asking questions; a report that was never sent cannot.
The three lines to copy
The application keeps a log on your machine, locally. To open it: the same menu as "About", then the "Log folder" row. If the system refuses to open the folder, the application shows the path with a "Copy" button.
The file itself:
%USERPROFILE%\.debugxmltool\logs\debugxmltool.log
At the start of every session, the log writes three lines of this shape. Those are the ones:
=== Debug XML Tool — session du … ===
version=… vendor=Debug XML Tool build=…
os=… java=… locale=…The file is never emptied: it grows at each start, and the current session is at the end, not at the beginning.
Some technical lines show broken accented characters. Copy them as they are: it is a display defect on our side, with no effect on reading them.
What that log contains — read it before sending it
We will never ask you for "the log". Here is why, and what you will see if you open it.
- Every file path is written in full. On a work machine that includes your Windows account name, and often a client or project name inside the path itself.
- XML parser errors quote the document: file name, line, column, and the name of the element at fault. In an integration stylesheet, those element names are your client's data model.
- The log also records the workspace you opened, the files you loaded, the lines where you set breakpoints and the names of the files produced. A generous excerpt draws a map of your project.
What it never contains is your license key, your machine fingerprint or your email address: that is a rule of the product, precisely because this file is meant to be sent.
Hence the instruction: copy the session header and the error lines, not the file. Read them again. Replace what has to be replaced — a redacted excerpt is still useful.
Redacting, in practice
As it appears in the log:
[Fatal Error] C:\Users\dupont\clients\ACME\invoices.xml:8:5:
The end-tag for element type "amount_net" must end with a '>' delimiter.Fit to send:
[Fatal Error] <file>.xml:8:5:
The end-tag for element type "<element>" must end with a '>' delimiter.The line, the column and the nature of the error are enough to reproduce it. The real file name and the real element name add nothing.
What not to send
Integration XSLT is done in banking, insurance, the public sector and healthcare. There, the stylesheet is client data, and sending it is not a matter of tact: it is contractually impossible.
So do not attach your stylesheet, your XML documents or your output. We will not ask for them, and their absence is not an obstacle.
If the problem reproduces on a document you can share — ten made-up lines are often enough — that is a gift. It is not a condition.
If the application closed on its own
An unexpected shutdown leaves a trace in the log, on a line starting with [Crash] and carrying a plain-language summary. That is the line to copy, along with the few technical lines that follow it.
[Crash]
If you find no such line, say so: that tells us something too.
Where to send it
An address, not a form: that way you keep a record of what you sent, in your own mailbox.
What happens next, and what does not
A person reads it. There is no automatic queue, no ticket number, and no response time is promised.
The application checks for no updates: a fix will therefore not reach you on its own. The only possible way back is the address you write from, and the notice is sent by hand.
You can also check for yourself, whenever you want:
Reporting a problem does not subscribe you to any mailing list. Your address is used for this exchange and nothing else.
What this page is not
- There is no public tracker. Reporting a defect in a work tool should require neither creating an account nor complaining in public.
- Nothing is sent automatically from the application, now or later: you write, and you read it over before sending.
- This is not a phone support line, and there is no on-call rota.