PCM Hammer - The Uno UI, Improvements, and priorities

[antus]

Great. 10 with ESU is currently showing version 19045.7058.

I've had some reports (thanks, Ron!) that he has a P11 which is failing to read CRCs with a PCM crash on this version. The same kernel on my PCM with the same service number is fine and I can't reproduce. We've tried higher voltages, no difference and another tool which does work on it, so the hardware seems ok. Therefore I'd like to tag P11 as still under development until we get to the bottom of this. I'll send a quick pull request to get that in to develop and it should merge cleanly with the uno branch.

[NSFW]

I really should have renamed the PR before I merged it, but oh well.

"Develop merged into the Uno branch" is how I prepared for the merge back into develop... but it's still called that even though "Uno merged into develop" is what really happened in the end.

[crowbarmaster]

Perfect!

I just accomplished native control of Bluetooth in windows! It involved placing the core of that in its own .NET10 lib, as I had found out that InTheHand as a NetStandard lib doesn't play nice with Windows 11. With that change I can now connect to paired devices without the use of Virtual COMs. I will filter those out of the serial port list as well and that will help with the port clutter.

I re-arranged the settings window to accommodate this new addition and things work pretty well! I think ill clean things up and stop writing for a minute so we can all review. I still need to fix the labels to always be more generic too.

Screenshot 2026-04-09 074633.png

[antus]

Ive merged develop back in to the antus/p11 branch because I have another set of changes to sync up and test before sending a pull back to develop.

Good work though, I can build and see and use the uno interface. Looking good on a P11 read:

Screenshot 2026-04-10 014704.png

But then it failed during checksum at the end. Which might actually be good because Ron has reported crash during checksum on his PCM and this is the first time I have seen it on mine (same service number)... So it could be a real problem and maybe I can reproduce it now.

Down side is I don't think we have debug output available in this build?

Screenshot 2026-04-10 015019.png

Anyway I can keep looking in to that.

Ive also been trying to get the checkbuild to work for the new targets, but I cant run that locally so Im pushing changes up to github. The latest is here https://github.com/PcmHammer/PcmHammer/ ... 4201201648

I need some sleep though so Im going to stop here and check if this one fully worked or not in the morning.

[crowbarmaster]

I'm glad you finally had the chance to give it a spin!

I'm about half way done organizing changes into commits, I'm going to make a push tonight to get that finished so I can produce a test branch.

There is a button in the Help page that will allow viewing and saving debug output. I myself though would probably like to see an optional checkbox in the window or settings that would change that to a debug feed.

Curious to know if real-time logging sounds like a good idea for this project. My idea of logging is standalone, and written directly to file. I also typically put a method on the event handler attached to unhandled exceptions so those get logged on the way out. I went a bit further too: Allowing a new logger instance passed into a read/write creates a dedicated log for the action. I made that work well with the existing interfaces, (Although there may be more here to consider with Uno) so there was no real change needed for catching the logs. I also toyed with the ideal of using the IProgress interface over adding those to the logger, that worked well too. This however was just going to be a suggestion and I can easily work around without that.

I'm going to upload that demo I made before I got here tonight. I think if anything it'll give you guys an idea of how I think these issues out. I'll drop a link afterwards!

[NSFW]

Debug messages are in there somewhere...

EDIT: there's a "View Debug Log" button on the Help page.

[sparepartsblazer]

I just tried to open the last version and it wont open.

[antus]

Yep checkbuild winforms isnt working yet with that configutation. Its building but that happens. Working on it. It works when you build it locally, same source code.

I will admit, ai is proving very helpful for this..

Working for 2m 31s
Yes, we can inspect this directly. I’ll run the artifact PcmHammer.exe, capture its exit behavior, then pull recent Windows Application/.NET Runtime event log entries for that process to identify the crash reason without needing UI interaction.


Ran 3 commands
Artifact repro is clear: it crashes immediately with a managed exception code, while local build stays alive. I’m now pulling .NET Runtime and Application Error event entries to get the exact exception and faulting module.


Ran 2 commands
Root cause is now narrowed to an unhandled System.IO.FileLoadException during MainForm.InitializeComponent() (resource loading path). I’ll inspect the WER report file next to extract which assembly/resource failed to load.


Ran 1 command
I can go one level deeper with Fusion binding logs to identify the exact assembly/resource load that throws FileLoadException. I’ll enable per-user Fusion logging, run the failing EXE once, then read the generated bind-failure log.

... and we continue ...

[sparepartsblazer]

Yep checkbuild winforms isnt working yet with that configutation. Its building but that happens. Working on it. It works when you build it locally, same source code.

Ok. Will try it again this weekend. Building from source code is way out of my wheelhouse

[antus]

Yep cool. Got a lead / possible solution on this but changes of the app and build versions and everything are very heavy versus the older .net version and build process so there is probably another problem right around the corner....

here 'I' is codex-5.3

Yes, and I was able to identify it.

What I used

Ran the artifact EXE directly and checked process lifetime/exit code.
Queried Windows Application logs (.NET Runtime event 1026 and Application Error 1000).
Reproduced locally by building with the same CI MSBuild flag.
What it shows

Artifact PcmHammer.exe exits immediately with -532462766 (0xe0434352, unhandled managed exception).
Event log shows:
System.IO.FileLoadException
Crash occurs in PcmHacking.MainForm.InitializeComponent() during resource loading.
I then rebuilt local WinForms with the same CI property:
-p:GenerateResourceUsePreserializedResources=true
Local build then also crashes immediately with the same exception.
So the failure is not random packaging corruption; it is tied to that build property/its resource loading behavior.
Root cause (high confidence)
GenerateResourceUsePreserializedResources=true is producing WinForms resources that fail to load at runtime in this app/environment, causing startup crash before UI appears.

Recommendation
Remove that property from the WinForms CI build steps (or only apply it where strictly required). That should restore startup behavior to match your working IDE build.