win32 · Step 7. Troubleshooting

This collects problems actually encountered while building and running TMC Suite for 32 bits, and their solutions. All solutions are already applied in the project; this section is for building from a "bare" source or if you hit the same symptom.

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 the field csTolerance.
• Affected: tmc_rth.exe, tmc_rtx.exe.
• Symptom: pressing "View statistics" (Shift+F4) tries to open the statistics window, and the whole program closes silently with no error message. Identical in H and X.
• Cause (established by debugging): the constructor had csTolerance.Format("100 %");. The string "100 %" is passed to CString::Format as a format string. The % character begins a conversion specifier, the space is treated as a flag, and then the string ends — producing an incomplete specifier. The modern UCRT (the printf engine: __stdio_common_vsprintf_s -> format_validation) treats this as an invalid parameter:
• in Debug a _CRT_ASSERT fires;
• in Release the CRT invalid-parameter handler fires -> silent process termination (exactly the observed symptom).

In the old compiler where the code was written, printf did not validate the format so strictly, so it did not crash before. - Fix (code change, math not affected): in both files csTolerance.Format("100 %"); was replaced with a direct assignment:

csTolerance = "100 %";

The resulting text is the same "100 %", but the formatting engine is not involved. (An alternative is Format("100 %%"), but assignment is cleaner.) - Verified: after the fix the "Statistics" window opens fully; the invalid-parameter handler no longer fires. - Status: closed.

Note: in CLAUDE.md/BUILD_ORDER.md this bug may be marked "not fixed" — that is an outdated note. The current status per the ISSUES.md log 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 error window "Encountered an improper argument"; after OK the application starts, but on "calling up a graph from a file" — the same error. When explicitly opening horns.soc, a hard abort 0xC0000409 (STATUS_STACK_BUFFER_OVERRUN) was observed. It appeared identically on win32 and win64, which means this is not bitness but unported viewer source code.
• Cause: 1. CTMCGROUTDoc::MakeDocFileName() called SetPathName(GetTitle()) and SetPathName(ch1) without the second argument bAddToMRU. By default it is TRUE -> MFC tries to add an incomplete path to the recent-files list (GetTitle() is a title like "TMCGROUT1"). Inside CRecentFileList::Add, GetFullPathName/AfxFullPath is called with an invalid path -> the CRT invalid-parameter handler fires -> a CInvalidArgException ("Encountered an improper argument"). 2. InitInstance() lacked AfxOleInit() (needed for Shell/COM in CRecentFileList on Windows 7+) and SetRegistryKey() (without it, settings/MRU are written to %WINDIR%\*.INI — a path not writable). 3. StdAfx.h lacked #include <afxdisp.h> (needed for AfxOleInit).
• Fix (code changes, math not affected):
• MakeDocFileName: SetPathName(GetTitle(), FALSE) and SetPathName(ch1, FALSE).
• InitInstance: added AfxOleInit(); and SetRegistryKey("<program name>") (keys: TMCGROUT, TMCROS, TMC_DN).
• StdAfx.h: added #include <afxdisp.h>.
• Files: in each of the folders Tmcgrout, Tmcrtout, DiaNapGr — TMCGROUT.cpp/TMCGROUT.CPP, TMCGROUTDoc.cpp, StdAfx.h.
• Verified: all viewers start without the error and open horns.soc without an abort.
• 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, and the file ~$Prepr$~ is not created. The process exit code is 0xC0000409 (STATUS_STACK_BUFFER_OVERRUN). Starting without a file works; the crash is only when opening a document. An 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: this is the same defect as Bug #5 (section 7.2), but not applied to the kernels and FieldView. In InitInstance there is LoadStdProfileSettings (the recent-files list, MRU) and RegisterShellFileTypes, but no AfxOleInit() (the kernels also lack SetRegistryKey). When a document is opened, MFC calls CDocument::SetPathName -> CWinApp::AddToRecentFileList -> CRecentFileList::Add, and it 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 this 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, and 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: 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.
• 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 string 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.

7.5 Library build errors (Phase 1) and their solutions

These changes are already applied (see 03-build-libs.md, section 3.0). If you build from unprepared sources, you may encounter:

• C1041 — several cl.exe writing into one .pdb. Cause — obsolete overrides ObjectFileName/ProgramDataBaseFileName=.\Release/. Solution: remove these overrides (use the defaults from IntDir).
• Toolset v100 not found — the project references VS2010, which is absent. Solution: switch Platform Toolset to v145 (project properties -> General).
• Hard paths E:\WORK, D:\work, Z:\work, d:\tmc\lib — headers/libraries are not found. Solution: remove these paths, attach build\Common.props / LibOutput.props.
• C2143/C2059 in MAINWNDW.H (the ETIME macro) — change C-1: before enum ST_ITEMS add #ifdef ETIME / #undef ETIME / #endif.
• C1083: error.h not found in SFILE95\Sadd.cpp — change C-2: replace #include <error.h> with #include <Error1.h>.

7.6 Kernel build errors (Phase 3) and FieldView (Phase 4)

• error C3861: 'outp'/'inp' not found in PL_GLFUN.CPP / Pl_glfun.cpp — change P-3: replace the port-access branch with Beep(freq, time) (see 05-build-kernels.md, section 5.0).
• /MACHINE:I386 in the linker — remove (unnecessary; incompatible with x64).
• C1083: gl\glaux.h not found in FieldView — change F4-1: remove #include <gl\glaux.h> and remove glaux.lib from the linker (see 06-build-fieldview.md, section 6.2).

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

Check:

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

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

This is a mandatory point when building from a "bare" source. If you skip it, the X-mode (tmc_rtx) computes seemingly normally, but the field gradually develops "rippling" and diverges.

• Affected: tmc_rtx.exe (X-mode). The H-mode is stable even in float, so the symptom is only visible in X.
• Symptom: in a computation (e.g. samples\SAMPLE_R\ABSORBER\POLY.TPL) the field in FieldView becomes covered with growing "rippling", the wave "freezes", the amplitude grows over time; a single pulse does not fully decay and then swings up again.
• Cause: in the shared header src\Include\Typerth.h, single precision _PREC_FLOAT (_real = float, 4 bytes) was active instead of double _PREC_DOUBLE (double, 8 bytes). The 6-component X-mode scattering scheme is non-dissipative, marginally stable (the eigenvalue of the step operator ≈ 1.0): in float the rounding error systematically accumulates and slowly swings the field; in double the field stays bounded. This is NOT the compiler — building the same sources on VS2008 in float breaks the same way; an A/B check of x87 (/arch:IA32) vs SSE2 gives identical growth. A numerical comparison with the 2006 reference version: the double build matches it to ~6 significant digits and damps the pulse, the float build diverges. Full analysis — ISSUES.md, Bug #11.
• Solution (applied): in src\Include\Typerth.h keep //#define _PREC_FLOAT #define _PREC_DOUBLE and rebuild ALL components (6 libraries + kernels + viewers + FieldView), because _real is part of the shared structures (ABI) and of the file format. The field element size sizeof(_real) becomes 8 bytes (header #TMCGROFLD_Accuracy 8); all readers (viewers, FieldView) are also built as double and read it correctly (the format is self-describing).
• Check: verify that after the computation the field file has #...Accuracy 8, and the pulse computation decays.
• Status: closed. The computation math was not changed — the original double precision was restored.