So you think you have found a bug and would like to report the problem? Before reporting a bug please ensure you have applied all applicable updates to your build environment, and also search the MinGW.OSDN mail archives, and the MinGW.OSDN “Issues” ticket system, to ensure the bug has not already been reported, or if a temporary workaround has been suggested. (When searching within the ticket system, please ensure that you include “Closed” tickets; it may be that a solution is already available, pending a future release).

To ensure that your report will be given the utmost attention, please read and follow the guidelines below. These are provided for your benefit, as non‑compliance may result in rejection of your bug report. Although they apply, in this specific context, to reporting via the MinGW.OSDN ticket system, these recommendations are typical of any bug reporting process.

Guidelines for Submission of Bug Reports

For general guidance on How to Report Bugs Effectively, you are encouraged to read this treatise by Simon Tatham. Do note, however, that to report MinGW bugs, you should use the reporting facilities documented below; do not report MinGW bugs to Simon — he is unlikely to be interested.

When reporting a bug to one of the MinGW mailing lists or to the MinGW Issues ticket system on OSDN.net, please include as much as possible of the following information, pertinent to the problem:

Host Operating System Information and Version
Your build environment will probably not be the same as our defaults, so it will helpful if you give us some information about your setup; in particular, please specify which version of Windows you are using, be it Windows‑95, Windows‑98, Windows‑ME, Windows‑NT, Windows‑2000, Windows‑XP, Windows‑Vista, Windows‑7, Windows‑8, Windows‑8.1, or Windows‑10; alternatively, if you are using a MinGW‑compatible cross‑compiler suite, please provide details of the system on which you are running it.

If you are working on a native MS‑Windows host, please tell us whether you are running the compiler suite from Microsoft’s cmd.exe, or if you are using a Bourne shell environment, such as MSYS, or Cygwin. (Do please note that modern Cygwin is effectively equivalent to the use of a cross‑compiler suite, on a non‑Windows host; very old Cygwin versions exhibit behavioural similarities to MSYS, but if you are still using one of these — characterized by use of the ‘gcc -mno-cygwin ...’ command to enter MinGW compilation mode — you should definitely seek to upgrade).

If you are using the MSYS Bourne shell, please show us the the output produced by running the command:
```
$ uname -a
```
Furthermore, if you are using RXVT as the container in which to run the MSYS shell, then please confirm that the bug is also present if you run the shell in a native MS‑Windows console, (i.e. by starting MSYS with the -norxvt option, or by moving rxvt.exe out of the way, before starting MSYS).

GCC Version and Configuration
If you are using a MinGW‑GCC compiler suite, running on a native MS‑Windows host system, the GCC compiler version, and configuration, can be determined by running the following command (either from Microsoft’s cmd.exe prompt, or from an MSYS Bourne shell prompt):
```
$ gcc -v
```
If you are using a MinGW‑compatible cross‑compiler, the command is effectively the same, but with ‘gcc’ qualified by the appropriate host prefix; e.g. if your cross‑compiler is characterized by the ‘mingw32’ host prefix, you would invoke the equivalent of the preceding command as:
```
$ mingw32-gcc -v
```
Regardless of which form you use to invoke it, the output from the preceding command will tell us which version of GCC you are using, whether it is operating on the basis of built‑in ‘specs’, or it is using an external ‘specs’ file, (of which you should provide a copy), and the options with which GCC was configured. Please post the output from this command in its entirety, (i.e. copy‑and‑paste it); do not trim, or exclude any part of it.

GNU Binutils Version
The GNU binutils suite is a prerequisite of the GCC compiler suite, (providing the assembler, and linker, among other utilities). The installed version must be consistent with the GCC requirement; you may verify this by running the linker command:
```
$ ld -v
```
or the cross‑compiler equivalent, (once again, assuming a host prefix of ‘mingw32’):
```
$ mingw32-ld -v
```
As in the case of GCC version identification, the output from this command will indicate the binutils version; please post it in its entirety, (i.e. copy‑and‑paste it); do not trim, or exclude any part of it.

MinGW Runtime Library and Windows API Version
Since the majority of bugs, which are directly attributable to MinGW, will, in some way, be related to the MinGW Runtime Library, or its associated Windows API implementation, it is imperative that you tell us which versions of these you are using; these may be identified by running (in the MSYS shell):
```
$ echo "#include <windows.h>" | gcc -E -dM -xc - | egrep "(MINGW32|W(IN|32)API)_VERSION"
```
or its equivalent with a cross‑compiler suite, (with a host prefix of, e.g. ‘mingw32’):
```
$ echo "#include <windows.h>" | mingw32-gcc -E -dM -xc - | egrep "(MINGW32|W(IN|32)API)_VERSION"
```
If you are running the compiler suite from Microsoft’s cmd.exe prompt, identification of these package versions becomes rather more awkward:
1. Firstly — unless you have an external (third‑party) implementation of echo.exe (or a suitable alternative), which mimics the Bourne shell interpretation of quoted arguments — the command:
```
C:\> echo "#include <windows.h>"
"#include <windows.h>"
```
  will leave the enclosing quotes in place, resulting in an invalid statement to be passed through the pipe, to gcc. Omitting the quotes isn’t an option, because the “<” and “>” angle brackets, which enclose <windows.h>, will be interpreted as redirection operators, and will invalidate the syntax of the echo command itself:
```
C:\> echo #include <windows.h>
The syntax of the command is incorrect.
```
  Escaping the angle brackets yields the required output:
```
C:\> echo #include ^<windows.h^>
#include <windows.h>
```
  but even this isn’t sufficient, when this output is piped to gcc:
```
C:\> echo #include ^<windows.h^> | gcc -E -dM -xc -
The syntax of the command is incorrect.
#define ...
...
```
  It appears that construction of the pipeline causes the command to be parsed twice, and that the escaped angle brackets are reinterpreted as redirection operators, on the second parse. To correct this, the angle brackets must be escaped twice:
```
C:\> echo #include ^^^<windows.h^^^> | gcc -E -dM -xc -
#define ...
...
```
2. Secondly — unless you have a third‑party implementation of egrep.exe (or a suitable alternative) — it may be necessary to use Microsoft’s find command; since this does not support regular‑expression matching, each version tag match requires a separate command invocation.
```
C:\> echo #include ^^^<windows.h^^^> | gcc -E -dM -xc - | find "MINGW32_VERSION"
#define MINGW32_VERSION ...

C:\> echo #include ^^^<windows.h^^^> | gcc -E -dM -xc - | find "W32API_VERSION"
#define W32API_VERSION ...
```
Given the above limitations, emulation of the recommended Bourne shell command for identification of the installed MinGW Runtime Library version, and the associated Windows API version, from Microsoft’s cmd.exe, without the assistance of any third‑party utility programs, may require a command sequence such as:
```
C:\> for %T in (MINGW32 W32API WINAPI) do @(
More? echo #include ^^^<windows.h^^^> | gcc -E -dM -xc - | find "%T_VERSION"
More? )
#define MINGW32_VERSION ...
#define W32API_VERSION ...
```
which does appear to achieve the desired result, at least when run from cmd.exe on Windows‑XP.

Minimal Self-Contained Test Case
A simple test case is the only way to reproduce a bug, if code doesn't behave as expected or won't compile. Trim your source code to the minimal set of statements needed to demonstrate the bug, and eliminate dependencies on headers, other than those provided as components of a standard MinGW installation; (if you cannot eliminate such external header dependencies, then please consider that your bug report should, more than likely, be directed to the project providing those headers).

Unless you are reporting a failure of MinGW to compile code, which you believe to be valid, the test case should be compilable, directly from the command line, using only tools which are provided by the MinGW Project. It should be reduced to a single compilation unit. Do not post code that has to be modified, in order to demonstrate the bug. Do not post project files requiring the use of any IDE, (Integrated Development Environment), even if that IDE relies on MinGW to furnish its compiler suite.

If you are reporting failure to compile code, which you believe to be valid, then please double check against the relevant standards, to ensure that your code really is valid; it is, alas, all too common to see such reports, where the test case is definitively invalid.

Documentation or References
If the bug is related to a missing MS‑Windows API, or MinGW Runtime feature, please give us links to references and/or documentation which will facilitate the implementation of the feature. A good source of documentation is MSDN (Microsoft Developer Network). Conversely, information abstracted from any Microsoft SDK, or even from a code base published under the GNU General Public Licences, (GPL or LGPL), is not a good source; the licences governing the redistribution of such information are not compatible with MinGW's public domain paradigm, and such information is, therefore, not accepted as a basis for implementation of MinGW features.

Please also include, in your post, the version of your mingw-runtime, (found in header file _mingw.h), and of w32api, (found in header file w32api.h).

Any Other Detailed Information
Any other detailed information, which is pertinent to your experience with the bug, will always be appreciated and may be helpful.

Guidelines for Submission of Bug Reports

Generic Package Bugs

Posting a Bug Report

In Case of Difficulty