win64 · Step 7. Troubleshooting

This collects problems of building and running TMC Suite for 64 bits and their solutions. All solutions are already applied in the project. Purely 64-bit code changes are moved to a separate log 08-porting-changes.md — only references to them are given here.

7.1 The "Statistics" button crashes the program (H and X modes) — Bug #1 · FIXED

• Where: kernels\PlanarRT_H\TmcDialogStatistics.cpp and kernels\PlanarRT_X\TmcDialogStatistics.cpp, the constructor CTmcDialogStatistics::CTmcDialogStatistics, initialization of csTolerance.
• Affected: tmc_rth.exe, tmc_rtx.exe.
• Symptom: pressing "View statistics" (Shift+F4) tries to open the window, and the program closes silently with no message. Identical in H and X (and identical on win32 and win64 — this is not bitness).
• Cause (established by debugging): the constructor had csTolerance.Format("100 %");. The string "100 %" goes to CString::Format as a format string: % begins a specifier, the space is a flag, then the string ends -> an incomplete specifier. The modern UCRT (printf: __stdio_common_vsprintf_s -> format_validation) treats this as an invalid parameter:
• in Debug — _CRT_ASSERT;
• in Release — the CRT invalid-parameter handler -> silent process termination.

In the old compiler printf did not validate the format so strictly. - Fix (code change, math not affected): in both files csTolerance.Format("100 %"); -> csTolerance = "100 %"; (direct assignment; the text is the same "100 %", the format engine is not involved). - Verified: the "Statistics" window opens fully; the Release builds of tmc_rth/tmc_rtx (win32 and win64) were rebuilt with the fix. - Status: closed.

In CLAUDE.md/BUILD_ORDER.md the bug may be marked "not fixed" — that is an outdated note; per ISSUES.md it is fixed.

7.2 Viewers: "Encountered an improper argument" at startup — Bug #5 · FIXED

• Where: TMCGROUT, TMCROS, TMC_DN (shared viewer code).
• Symptom: at startup — the MFC window "Encountered an improper argument"; after OK the application starts, but on "calling up a graph from a file" — the same error. When opening horns.soc — an abort 0xC0000409 (STATUS_STACK_BUFFER_OVERRUN). Identical on win32 and win64 -> not bitness but unported viewer source code.
• Cause: 1. CTMCGROUTDoc::MakeDocFileName() called SetPathName(GetTitle()) and SetPathName(ch1) without the second argument bAddToMRU (default TRUE). MFC tried to add an incomplete path to the recent-files list (GetTitle() is the title "TMCGROUT1"); CRecentFileList::Add -> GetFullPathName/AfxFullPath with an invalid path -> CInvalidArgException. 2. InitInstance() lacked AfxOleInit() (Shell/COM for CRecentFileList) and SetRegistryKey() (without it, settings/MRU are written to %WINDIR%\*.INI). 3. StdAfx.h lacked #include <afxdisp.h>.
• Fix (math not affected):
• MakeDocFileName: SetPathName(GetTitle(), FALSE), SetPathName(ch1, FALSE).
• InitInstance: AfxOleInit(); and SetRegistryKey("<program name>") (keys TMCGROUT, TMCROS, TMC_DN).
• StdAfx.h: #include <afxdisp.h>.
• Files: in Tmcgrout, Tmcrtout, DiaNapGr — TMCGROUT.cpp/TMCGROUT.CPP, TMCGROUTDoc.cpp, StdAfx.h.
• Verified: all viewers (win32 and win64) start without the error and open horns.soc.
• Status: closed.

7.3 Kernels (tmc_rth/tmc_rtx) and FieldView crash when opening a file — Bug #6 · FIXED

• Where: kernels\PlanarRT_H\PlanRT_H.cpp and kernels\PlanarRT_X\PlanRT_H.cpp (the function CPlanRT_HApp::InitInstance); fieldview\FldView.cpp (CFldViewApp::InitInstance).
• Affected: tmc_rth.exe, tmc_rtx.exe, FieldView.exe.
• Symptom: when opening any computation file .tpl (for the kernels) or a field file .dat (for FieldView), Windows shows "The parameter is incorrect", the program closes silently, the file ~$Prepr$~ is not created. The process exit code is 0xC0000409 (STATUS_STACK_BUFFER_OVERRUN). It appears identically on win32 and win64 — this is not bitness. Starting without a file works; the crash is only on opening a document. Additional effect: FieldView "is not called" from the kernel — the "View Field and topology" button seems to trigger, but no window appears and there is no error: the kernel launches FieldView via CreateProcess (successfully), and FieldView itself crashes instantly for the same reason.
• Cause: the same defect as Bug #5 (section 7.2), but not applied to the kernels and FieldView. In InitInstance there is LoadStdProfileSettings (recent files, MRU) and RegisterShellFileTypes, but no AfxOleInit() (the kernels also lack SetRegistryKey). When a document is opened, MFC calls CDocument::SetPathName -> CWinApp::AddToRecentFileList -> CRecentFileList::Add, which throws an unhandled CInvalidArgException (AfxThrowInvalidArgException). Nobody catches it -> terminate() -> 0xC0000409 -> the system shows "The parameter is incorrect". The crash happens in SetPathName before the data is read, which is why the preprocessor never creates ~$Prepr$~. In the old compiler/environment it did not crash.
• Fix (initialization code change, math not affected):
• In CPlanRT_HApp::InitInstance (both kernel folders), AfxOleInit(); and SetRegistryKey("PlanarRT_H") / SetRegistryKey("PlanarRT_X") were added at the beginning.
• In CFldViewApp::InitInstance, AfxOleInit(); was added, the default SetRegistryKey("Local AppWizard-Generated Applications") was replaced with SetRegistryKey("FieldView").
• In kernels\PlanarRT_H\StdAfx.h and kernels\PlanarRT_X\StdAfx.h, #include <afxdisp.h> was added (FieldView already had it).
• Effect: settings and MRU are now written to the registry HKCU\Software\<key>, not to the inaccessible %WINDIR%\*.INI.
• Verified: all 4 kernel configurations (tmc_rth/tmc_rtx × win32/win64) and FieldView (win32/win64) were rebuilt; opening .tpl/.dat no longer crashes, ~$Prepr$~ is created, FieldView launches and draws fields.
• Status: closed.

Note: this bug is not about bitness (it appears and is fixed identically on win32 and win64), so it stays in this section, not in 08-porting-changes.md. The detailed symbolized crash stack is in the ISSUES.md log (Bug #6).

7.4 "The parameter is incorrect" when opening TEST_EPS.TPL (out-of-range string access in ReadSmatrix) — Bug #7 · FIXED

• Where: src\libs\TMCIndan\TmcRTH_IndanOutput.cpp, the method CTmcRTH_IndanOutput::ReadSmatrix, the loop searching for the extension dot in the S-file name (around lines 468–475).
• Affected: tmc_rth.exe, tmc_rtx.exe (code in the shared library TMCIndan).
• Symptom: after fixing Bug #6 the kernels open almost all .tpl, but specifically samples\TPL\TEST_EPS.TPL shows, on opening, a modal window "The parameter is incorrect." with an OK button. This is not a crash — the process stays alive (waiting for OK). Other .tpl files compute normally, identically on both platforms.
• Cause: an index typo — in the loop the access is csFileNameSMatrix[i] instead of csFileNameSMatrix[j]. The loop should iterate over the name characters via j, but it reads a fixed index i — the parse offset of the SMATRIX line (~17), whereas the name test1071 is 8 characters long. In modern MFC, CString::operator[] with an index strictly greater than the length throws AtlThrow(E_INVALIDARG) -> COleException with code 0x80070057 (which is HRESULT_FROM_WIN32(ERROR_INVALID_PARAMETER)). The exception is thrown while reading the OUTPUT section (in OnInitialUpdate -> ReadData); the standard MFC handler CWinApp::ProcessWndProcException -> CException::ReportError -> AfxMessageBox shows the system text "The parameter is incorrect". The old compiler in Release did not check the index (it silently read garbage), so it "worked" before.
• Why only TEST_EPS: the exception arises only when the index exceeds the name length. The neighboring FILE reading method (ReadFile) has a similar loop that starts at an index equal to the string length (which is allowed — operator[] with an index equal to the length returns '\0' and does not throw), so it is safe for all files. In ReadSmatrix the index noticeably exceeded the length for this particular file/name.
• Fix (index typo, not math): the broken loop was replaced with a safe check for the presence of a dot in the name via strchr:

n = ( strchr( szBuf, '.' ) != NULL ) ? 1 : 0;

(where szBuf is the same file name). The meaning is preserved: if the name has no extension dot, .s is appended below. - Rebuild: the TMCIndan.lib library was rebuilt (win32+win64), then the kernels tmc_rth/tmc_rtx (win32+win64) and FieldView were relinked. - Verified: all 4 kernels open TEST_EPS.TPL without the error window, ~$Prepr$~ is created; a control run showed that the message window is no longer raised. - Status: closed.

Note: this bug is not about bitness (it appears and is fixed identically on win32 and win64), so it stays in this section, not in 08-porting-changes.md.

7.5 64-bit compilation errors — where to find the solution

All changes required specifically because of the move to x64 are described in detail in the log 08-porting-changes.md. Briefly:

• C2555 (return-type mismatch of DoModal) -> P-1: int DoModal() -> INT_PTR DoModal(). Viewers and FieldView.
• C2440/C2737 (the ON_WM_TIMER message map) -> P-2: OnTimer(UINT) -> OnTimer(UINT_PTR). Viewers and FieldView.
• error C3861: 'outp'/'inp' not found -> P-3 (needed for win32 too): the port-access branch was replaced with Beep(). Kernels H and X.
• C1083: gl\glaux.h not found -> F4-1 (needed for win32 too): the dead include was removed, glaux.lib was removed. FieldView.

The full justification of each change, with the files and the confirmation "the math is not affected", is in 08-porting-changes.md.

7.6 Settings build errors (shared with win32)

• C1041 (several cl.exe into one .pdb) -> remove the overrides ObjectFileName/ProgramDataBaseFileName=.\Release/.
• Toolset v100 not found -> switch to v145 (Properties -> General).
• Hard paths E:\WORK, D:\work, c:\tmc -> remove, attach Common.props/LibOutput.props/ExeOutput.props.
• /MACHINE:I386 in the linker -> remove (incompatible with x64).
• C2143/C2059 (the ETIME macro) -> C-1: #ifdef ETIME / #undef ETIME / #endif before enum ST_ITEMS in MAINWNDW.H.
• C1083: error.h not found -> C-2: #include <error.h> -> #include <Error1.h>.

7.7 Linking fails: "library *.lib not found"

1. All 6 Phase 1 libraries are in dist\win64\lib.
2. Common.props is attached in the project (it adds dist\win64\lib to Library Directories).
3. The Release configuration and x64 platform match for the libraries and the program. You cannot link a 64-bit program with a library built for Win32.

7.8 OpenGL: the linker cannot find opengl32.lib/glu32.lib

• Make sure the Windows SDK is installed (see 01-requirements.md).
• For the x64 platform the libraries are taken from um\x64. The name in the linker is opengl32.lib (the same for x86/x64; VS picks the right bitness). There is no separate "OpenGL64".
• glaux.lib must not be in the link list (see F4-1).

7.9 X-mode: field "ripple"/instability — building in float instead of double — Bug #11 · FIXED · KEY

This is not bitness (it appears identically on win32 and win64) — it is the precision of the _real type. Be sure to check it when building from a "bare" source.

• Affected: tmc_rtx.exe (X-mode). The H-mode is stable even in float.
• Symptom: in FieldView the field develops growing "rippling", the wave "freezes", the amplitude grows; a single pulse does not fully decay and then swings up again.
• Cause: in src\Include\Typerth.h, single precision _PREC_FLOAT (_real=float, 4 bytes) was active instead of double _PREC_DOUBLE (double, 8 bytes). The X-mode scattering scheme is marginally stable (the step eigenvalue ≈1.0): in float rounding accumulates and swings the field, in double it does not. NOT the compiler (VS2008 in float breaks the same way, x87 vs SSE2 identical). A comparison with the 2006 reference: double matches to ~6 digits and damps the pulse.
• Solution (applied): in src\Include\Typerth.h keep #define _PREC_DOUBLE (and //#define _PREC_FLOAT) and rebuild ALL components for x64 (and win32) — _real is part of the ABI of the shared structures and of the file format. sizeof(_real) -> 8 bytes (#TMCGROFLD_Accuracy 8); the viewers/FieldView are built as double and read this correctly.
• Full analysis — ISSUES.md, Bug #11; the same solution in win32\07-troubleshooting.md § 7.8.
• Status: closed. The math was not changed — the original double precision was restored.