Where can I find definitions for the large proportion of messages types generated by my Garmin devices which are not defined in Profile.xlxs?

Check Integrity looks at the header and the CRC, it does not look at the data in the file. 

Running Decode::CheckIntegrity on my re encoded file did show me a problem. The decoder doesn't just discard unknown messages but rather returns a message with a null profile. When this is passed to the encoder to write, the encoder has a null validator and so skips validation and writes gibberish. All I had to do to fix it is to return from OnMesg without re encoding unknown messages by checking  mesg.GetNum() == FIT_MESG_NUM_INVALID).

After the fix, I no longer see gibberish in place of unknown messages if I fitprint or fitdump and CheckIntegrity and passes.

Also, FitTestTool still passes.

Sadly, Garmin still rejects the file. 

Yes, CheckIntegrity doesn't catch the problem but it does call ReadByte on the entire file and ReadByte throws an exception when it tries to decode data for which it doesn't have a matching message definition.

Perhaps, if I run a full decode on my current re encoded file, it will throw an exception and lead me to the remaining problem.

Thanks a lot for getting me into a more productive line of thinking.

I know I would have had fewer problems if I constructed the file by repackaging the records like the other Fix utility does. But, it just seems like it should work this way as well and ultimately require a lot less code.

Oh well, I had no luck finding any more errors with the decoder. Apparently, the decoder used by the Garmin Connect service is quite different from the one provided by the C++ SDK. Too bad. Explicitly repackaging all the known messages that you would like to keep in a file when you only need to alter one kind seems like a huge amount of unnecessary code.

FIT is a binary file format and it does not matter which SDK, provided by Garmin or a third party, is used to encode the file or which SDK, provided by Garmin or a third party, is used to decode the file. All of the SDKs are interchangeable when it comes to encoding and decoding files.

After decoding a file, a platform may apply its own business logic to the data decoded from the file. Platform specific business logic is independent of the FIT SDKs.

I suppose it depends on whether you consider the "business logic" which categorizes the FIT file as invalid when uploaded to Garmin Connect and valid when uploaded to Strava as part of the decode process. I agree that the invalidating logic is not part of the publicly available decoders because I can successfully decode the file myself using the C++ SDK. But, unless I'm missing something, I have no access to these additional "business logic" validity checks. So, it is quite difficult to make the file conform to them. At this point, it seems that my only option is to work from the other direction by exactly following the example of the ActivityRepairTool.java to hopefully encode a minimal FIT file which Garmin will accept and then start adding additional messages types to preserve as much information from the original FIT file as possible.

Anyway, I hope to get back to building a robust model for predicting heart rate at some point :->

I have documented many messages, fields and values, see medium.com/.../beyond-the-fit-sdk-c9969430aeeb