Methods for finding new Trace Flags in SQL Server There are a lot of Trace Flags out there. Some are well-documented, some are not, and others found their way to default behavior status in the 2016 release. Aside from official support channels, Microsoft employees, etc., what are ways to find new trace flags?

I've read through a couple recent posts by Aaron Bertrand here and here, but didn't spot anything about new Trace Flags.

I copied the data and log file of mssqlsystemresource to a new location, and attached it like a regular database to poke through system tables and views, but didn't spot anything immediately. I considered taking a list of known Trace Flags, and looping through numbers not on that list, to see which ones DBCC TRACEON would allow, but wanted to ask the question here first. 

Assuming that the DBCC command to enable them has to check in with some resource to make sure the Trace Flag is valid, where does it reach out to? Is there a .dll or some other system file that holds a list?

I know the question casts a wide net, but what spurred this was reading about a Trace Flag with specific intended behavior alongside a new feature in 2016 that was not having the described effect. My initial thought was that perhaps the numbers were transposed somehow, like 7129 becoming 7219. I was hoping to get a list of valid trace flags within a range, say 7000-7999, to look for permutations. Testing them all, both as DBCC TRACEON flags and startup parameters would be quite a nuisance, combined with testing the results against the feature behavior.
There's nothing you can do to find the list except ask or pick them up from posts/slide decks/etc. The list only exists in the code, in a header file where the valid trace flag numbers are mapped to names in a big enum in the C++ code, and then the names are used in the rest of the code.

As Aaron said, you can enable any trace flag number, and if it doesn't do anything, or you don't exercise the functionality that the trace flag is relevant to, you won't notice any difference in behavior.

DBCC TRACEON doesn't check anything - as there's no run-time list of which numbers are valid or not - it just enables that trace flag number in a bitmap of what flags are set for that connection/globally.

The problem with having a validity check is that would expose which trace flags are valid, allowing them to be discovered. This way the 'valid list' is effectively obfuscated, which is what the SQL team wants.

Regarding Kin's suggestion in a comment that SQL Server should have select * from sys.available_trace_flags - Yes and no. There are many trace flags that are highly detrimental to performance and are only necessary for debugging problems under guidance from Product Support, but SQL Server could list the 'safe' flags.