Version 2.0.7710 doesn't works

[Dim3333]

Hi,

I installed, without issues, the last version (2.0.7710) but impossible to launch it. The icon appears in the systray and disppeared immediately.

For information, the previous version (v2.0.4.0) don't detected the lastest release and impossible to update manually.

[gawindx]

It's weird that you're having this problem again. You encounter the same symptoms as with the previous version and your previous issue.

I only see one thing, delete the keys from the registry again.

In my opinion, since the only modification at this level is the encryption of authentication information, first try to delete the values of "NutLogin" and "NutPassword" which are in the "Winnut \ Connexion" key.

It may be enough to unlock it.

For the undetected update, I think I know where it came from.

[Dim3333]

I had already done it before to post.

[gawindx]

I think I'll need a bit more info on your config:

• Windows version
• installation directory by default or not
• Nut version
• server hosting Nut (Synology ?)
• the parameters of WinNUT (as it does not start, an export of the registry key will suffice)
• the content of the WinNUT log file (I'm not at home so I have a doubt about the path)

In fact anything that can help me understand and if possible reproduce your problem.

Are you French speaking? if so, it may be easier to exchange in French (even if I prefer English for general understanding but it is a question of understanding each other before all between us).

[Dim3333]

OK pour échanger en français. Etrange ..... quand j'ai ecris ce post ..... j'avais desinstallé la version v2.0.4.0 et reinstallé la derniere. WinNut ne se lancait pas du tout. L'icone apparaissait dans le systray et disparaissait aussitot. J'avais supprimé la clé du registre et idem.

J'ai recommencé la meme chose aujourd'hui dans cet ordre : desinstaller la V2.0.4.0, supprimer la clé du registre puis installe de la 2.0.7710 et cette fois le logiciel se lance bien !!!! je n'y comprends rien ???

Je vais pouvoir comparer avec la v2.0.4.0 car avec cette version (v2.0.4.0), je rencontrais des deconnexions intempestives au serveur NUT. A suivre .....

[gawindx]

Effectivement, pas très logique.

j’ai effectivement fait une modification sur les paramètres (encryptage des identifiants de connexion) mais je n’ai pas rencontré de souci lors de mes tests, le rechargement et la modification des identifiants s’est correctement effectué lors du premier démarrage de la nouvelle version.

Pour essayer de comprendre le problème que tu rencontre, pourrait tu me faire une extraction de tes paramètres WinNUT, histoire de voir si je peux reproduire et améliorer ça.

Pour les problèmes de déconnexions, il y’a également eu des améliorations sur la stabilité mais un utilisateur rencontre des crash régulier lorsque son router revoit la nuit. Les symptômes sont mieux identifiés aujourd’hui mais je n’ai pas réussi à reproduire et corriger ce problème.

[Dim3333]

Effectivement les parametres de la precedente version, ont bien ete repris avec la nouvelle. Par contre, je rencontre le meme probleme qu'avec la version precedente, WINNut se deconnecte tout seul du serveur. Je clique sur Connexion -> Re-connecter et c'est reparti

Je ne trouve pas le fichier .log ?

[FileCity]

For the connection issue, I may have a clue... or not :) I've noticed WinNUT is not really logged in the NUT upsd daemon. Normally the clients that fully support the NUT protocol are logged-in so the server knows each of them. The daemon can then interact with logged clients if it's needed, like in a shutdown process... The daemon can wait for them to fully disconnect before killing itself, etc...

Example of the login of my BSD pfSense box into upsd: Feb 12 08:14:26 RasPi4 upsd[809]: User upsmon_remote@192.168.1.1 logged into UPS [apc1500]

My NUT server is on a Raspberry Pi 4 with upsched and all modules activated with debounced email paging. So I know if anything is wrong, all the time. And it's rock solid.

I see no legit login for WinNUT (from my computer x.10 address) since it's still not supporting the full protocol, please correct me if I'm wrong. This may cause issues or not, I don't know, but the WinNUT on my system is always able to fetch from upsd 24/7 without issues... But everything is always running. My 2 cents.

Il est possible de continuer en français si nécessaire.

[Dim3333]

English or french, as you like :)

Dans les logs, je lis : Connexion au Serveur NUT 192.168.x.x échouée : La valeur ne peut pas etre null.Nom du paramètre : value La déconnexion est trés aléatoire ..... apres plusieurs dizaine d'heures .... ou apres quelques minutes .... Pas facile pour debugger :) Je reitere la question de mon dernier post : où sont stockés les log ?

[gawindx]

@FileCity, ça me va pour le français sous réserve que tu sois aussi francophone.

Ta remarque n'est pas dénuée de sens mais je ne pense pas que cela vienne de là. J'ai moi aussi testé le fonctionnement sur plusieurs heures (prés de 36 d'affilée) en debug sous Visual studio pour pouvoir traquer d'éventuelles exceptions non gérées et rien, aucun problèmes.

WinNUT effectue une connexion via un socket TCP directement sur le port NUT et la connexion est maintenue via le polling donc, même si le protocole n'est pas parfaitement géré, la connexion reste parfaitement active et je réceptionne bien les signaux de type FSD (lancée depuis le serveur NUT en commande manuelle).

@Dim3333, pour le fichier log, il est dans stocké ici : %userprofile%\AppData\Roaming\WinNUT-Client\WinNUT-client.log

[FileCity]

@gawindx, serait-ce possible que dans un cas hypothétique la connexion ne soit pas maintenue ? Comme le serveur NUT ne voit pas la connexion comme 'logged-in', rien ne prévient celle-ci de tomber inactive, vu du serveur. Cela pourrait expliquer une partie des problème selon où le serveur NUT est installé (Linux, Synology, box X ou Y) etc... et la configuration de chaque système. Il serait intéressant de valider si il existe une certaine corrélation de ce côté.

[gawindx]

ça se tient.

Reste à savoir comment tester cela.

@Dim3333, quel est le délai de polling que tu as configuré?

Cela pourrait être un timeout côté serveur (un paramètre au niveau du démon?)

[Dim3333]

Intervalle : 5000

Le repertoire %userprofile%\AppData\Roaming\WinNUT-Client est vide ?

[FileCity]

Essayer 3000 dans ce cas, pour tester car les options sont limitées.

Et NUT n'est pas si facile quand on creuse les configs du serveur. J'ai du passer 1 mois à temps partiel à lire la documentation pour que tout soit exactement comme je le voulais. NUT est un package puissant mais difficile quand on a jamais travaillé avec ou sur Linux en général. J'ai du écrire aussi beaucoup de script en BASH pour gérer les self-test UPS a chaque semaine, etc... Et mon vieux UPS APC à aussi tendance à oublier certains settings programmés parfois, je dois détecter cela et corriger automatiquement avec UPSRW etc... C'est devenu plus complexe avec le temps mais le système se gère maintenant seul, et les client reviennent aussi avec du WOL si une panne est survenu, etc... tout est automatisé. Je recois des courriels régulier selon l'état du UPS, etc... Paranthèse hors sujet femée.

[gawindx]

Le fichier de log est une fonctionnalité optionnelle, il n'est donc pas crée par défaut.

Ci-dessous une capture des préférences où tu pourras trouver l'option:

[gawindx]

N'hésite pas à passer le niveau de journalisation en Débogue pour obtenir le maximum d'infos, ça pourrait aider.

[FileCity]

Ce document de Roger Price m'a beaucoup aidé. Introduction to Network UPS Tools - Configuration Examples ConfigExamples.A5.pdf

[Dim3333]

Niveau de journalisation passé en Débogue Intervalle réglé sur 3000

A suivre....

[gawindx]

j'ai rapidement passé en revue les fichiers de config de Nut et je n'ai pas trouvé d'info de timeout côté client. Je ne pense donc pas que cela vienne de là.

[Dim3333]

3000 ou 5000 .... meme chose.

Pourquoi ce saut entre 21:53 et 22:34 ?

Extrait du log, si ça peut aider :

12/02/2021 21:53:20Pid: 9784 UPS_Network : Enter Retrieve_UPS_Data
12/02/2021 21:53:20Pid: 9784 UPS_Network : Enter GetUPSVar
12/02/2021 22:34:07Pid: 9784 UPS_Network : Deconnect from Nut Host
12/02/2021 22:34:07Pid: 9784 String : New Log to CB_Current Log : Déconnectée du serveur NUT
12/02/2021 22:34:07Pid: 9784 UPS_Network : Force Disconnect
12/02/2021 22:34:07Pid: 9784 WinNUT : NotifyIcon Text => 
WinNUT - 2.0.7710
Reconnexion en cours
Essai 0 sur 30
12/02/2021 22:34:07Pid: 9784 WinNUT : Update Icon
12/02/2021 22:34:07Pid: 9784 UPS_Network : Deconnect from Nut Host
12/02/2021 22:34:07Pid: 9784 String : New Log to CB_Current Log : Déconnectée du serveur NUT
12/02/2021 22:34:07Pid: 9784 UPS_Network : Force Disconnect
12/02/2021 22:34:07Pid: 9784 WinNUT : NotifyIcon Text => 
WinNUT - 2.0.7710
Reconnexion en cours
Essai 0 sur 30
12/02/2021 22:34:07Pid: 9784 WinNUT : Update Icon
12/02/2021 22:34:07Pid: 9784 UPS_Network : Error When Retrieve_UPS_Data : La valeur ne peut pas être null.
Nom du paramètre : value
12/02/2021 22:34:07Pid: 9784 String : New Log to CB_Current Log : Connexion au Serveur NUT 192.168.1.72:3493 échouée : La valeur ne peut pas être null.
Nom du paramètre : value
12/02/2021 22:34:07Pid: 9784 UPS_Network : Autoreconnect Enable. Run Autoreconnect Process
12/02/2021 22:34:07Pid: 9784 String : New Log to CB_Current Log : Re-connexion Automatique
12/02/2021 22:34:07Pid: 9784 WinNUT : Nut Server Lost Connection
12/02/2021 22:34:07Pid: 9784 WinNUT : Fix All data to null/empty String
12/02/2021 22:34:07Pid: 9784 WinNUT : Fix All Dial Data to Min Value/0
12/02/2021 22:34:07Pid: 9784 WinNUT : Status Icon Changed
12/02/2021 22:34:07Pid: 9784 WinNUT : New Icon Value For Systray : 1344
12/02/2021 22:34:07Pid: 9784 WinNUT : New Icon Value For Gui : 1344
12/02/2021 22:34:07Pid: 9784 WinNUT : NotifyIcon Text => 
WinNUT - 2.0.7710
Connexion perdue à 192.168.1.72:3493
12/02/2021 22:34:07Pid: 9784 WinNUT : Update Icon
12/02/2021 22:34:13Pid: 9784 WinNUT : Restore Main Gui On Mouse Click Notify Icon
12/02/2021 22:34:14Pid: 9784 WinNUT : Main Gui Has Focus
12/02/2021 22:34:14Pid: 9784 WinNUT : Update Icon
12/02/2021 22:34:37Pid: 9784 WinNUT : NotifyIcon Text => 
WinNUT - 2.0.7710
Reconnexion en cours
Essai 1 sur 30
12/02/2021 22:34:37Pid: 9784 WinNUT : Update Icon
12/02/2021 22:34:37Pid: 9784 UPS_Network : Try Reconnect 1 / 30
12/02/2021 22:34:37Pid: 9784 String : New Log to CB_Current Log : Tentative de reconnexion 1 / 30
12/02/2021 22:34:37Pid: 9784 UPS_Network : Connect To Nut Server
12/02/2021 22:34:37Pid: 9784 UPS_Network : Enter AuthLogin
12/02/2021 22:34:37Pid: 9784 UPS_Network : Enter GetUPSVar
12/02/2021 22:34:37Pid: 9784 UPS_Network : Process Result With ups.mfr : VAR ups ups.mfr "American Power Conversion"
12/02/2021 22:34:37Pid: 9784 UPS_Network : Enter GetUPSVar
12/02/2021 22:34:37Pid: 9784 UPS_Network : Process Result With ups.model : VAR ups ups.model "Back-UPS CS 500"
12/02/2021 22:34:37Pid: 9784 UPS_Network : Enter GetUPSVar
12/02/2021 22:34:37Pid: 9784 UPS_Network : Process Result With ups.serial : VAR ups ups.serial "4B1417P47390  "
12/02/2021 22:34:37Pid: 9784 UPS_Network : Enter GetUPSVar
12/02/2021 22:34:37Pid: 9784 UPS_Network : Process Result With ups.firmware : VAR ups ups.firmware "808.q10 .I"
12/02/2021 22:34:37Pid: 9784 UPS_Network : Connection to Nut Host Established
12/02/2021 22:34:37Pid: 9784 String : New Log to CB_Current Log : Connexion au Serveur NUT 192.168.1.72:3493 établie
12/02/2021 22:34:37Pid: 9784 WinNUT : Update Icon
12/02/2021 22:34:37Pid: 9784 WinNUT : NotifyIcon Text => 
WinNUT - 2.0.7710
Connecté

[gawindx]

Juste pour être sur, ça ne pourrais pas être lié à une mise en veille?

WinNUT est programmé pour lancer la reconnections automatique (si active) à la sortie de veille. Par contre je n’ai ajouté de log pour cette routine ce qui fait que dans ce cas précis cela peu être totalement invisible dans les logs.

je vois pour te mettre à dispo une version spécifique avec l’ajout de log à la sortie de veille.

Personnellement, Windows m’a déjà fait la blague de modifier mes paramètres de mise en veille lors d’une mise à jour donc on ne sait jamais...

[Dim3333]

Possible que ce soit lié à la mise en veille.

Que se passe t-il lors que le PC est en veille et qu'il y a une coupure de courant ? WinNut est actif ?

[gawindx]

En gros, a la sortie de veille, les programmes en cours reprennent vie et un événement est généré par l’OS.

Donc si c’est une simple mise en veille et qu’il y’a une coupure, je pense que Windows va simplement démarrer normalement (et WinNUT aussi du coup). Si c’est une veille prolongée (ou hibernation), je dirais que Windows va reprendre son cours normal et ça sera une sortie de veille.

WinNUT verra alors l’événement et lancera la reconnection automatique si l’option est active, sinon il restera déconnecté (la deconnexion étant normalement effectué automatiquement à la mise en veille et de toute façon, le socket TCP ne survit pas à la mise en veille).

Le « trou » de 40 minutes dans tes logs pourrait correspondre à la mise en veille. Si c’est bien cela, WinNUT fonctionne correctement mais il manque une information claire aussi bien dans les logs qu’au niveau de l’interface pour en informer l’utilisateur.

[Dim3333]

OK, je teste de laisser le PC allumé toute la nuit et je verrai si demain il y a eu une déconnexion.

[FileCity]

Possible que ce soit lié à la mise en veille.

Que se passe t-il lors que le PC est en veille et qu'il y a une coupure de courant ? WinNut est actif ?

WinNUT ne sera pas actif durant une mise en veille. Il y a 2 types de mise en veille: suspend to RAM et hibernation. En suspend to RAM, le matériel reste en partie éveillé mais les différents composants sont mis en mode de basse consomation et le processeur en veille. La machine reste allumée en partie. Couper l'alimentation sur un ordinateur de bureau dans ce mode fera perdre les données du système. L'hibernation complète protège les données actives, Windows stop les processus en cours et sauvegarde la pile active et la mémoire dans un fichier sur le disque. Au redémarrage, Windows reprends le tout du disque vers la RAM et ré-exécute là où le système à été laissé. Dans ce mode les pertes de données sont peu probables.

[Dim3333]

Aucune déconnexion de la nuit, j'en conclu donc que c'est bien la mise en veille qui provoque la déconnexion. Mon PC est allumé 24h/24h et en veille classique (suspend to RAM) lorsqu'il n'est pas utilisé, dans ce cas, je comprends que WINNUT ne m'est d'aucune utilité s'il n'est pas en mesure d'arreter le PC proprement lors d'une coupure de courant.

[gawindx]

Je préfère que le problème viennent de la, c’est nettement plus cohérent. Je vais améliorer la journaliste on de cette fonction pour que ça soit plus clair à l’avenir.

Et malheureusement, ce n’est pas WinNUT qui ne t’ai d’aucune utilité dans ce cas, mais tous les logiciels du même type qui souffriront du même problème de mise en veille. Les deux seules alternatives que je voit sont :

• Ne pas utiliser de mise en veille
• Utiliser la mise en veille prolongée, ton pc étant déjà éteint une fois mis en veille il n’y aura aucun risque de perte de données.

[Dim3333]

Je comprends que tous les logiciels ne pourront répondre à mon besoin.

"- Ne pas utiliser de mise en veille" : Ecologiquement parlant, c'est pas terrible :)

"- Utiliser la mise en veille prolongée" : Pas pratique car ce PC est placé derriere un écran (VESA) et l'acces au bouton ON/OFF n'est pas simple (pour les enfants) et il n'est pas possible de sortir de cette mise en veille par le clavier (BIOS/Carte mere ne le permet pas)

L'onduleur est surtout utilisé pour un NAS et un serveur domotique, l'interet pour le PC est plus limité. En veille, il n'y a pas de données à proteger (rare que je laisse ouvert une application travail) mis à part eteindre le PC proprement plutot que de tirer sur la prise (façon de parler).

Content d'avoir contribuer (à une petite echelle) au developpement de WinNut Client. :)

[gawindx]

Pas de souci, et je n’ai pas dit que les alternatives étaient parfaites^^.

Rien n’empêche d’utiliser WinNUT uniquement pour avoir une vue sur l’état de l’onduleur en désactivant les fonctions d’arrêt.

Après tout, c’est cette fonctionnalité de visualisation qui est à l’origine du projet.

Et merci pour ton aide, même si ce n’était pas un bug, ça a permis de mettre le doigt sur un manque qui me semble assez important au final.

je ne ferme pas l’issue tout de suite, je le ferai quand j’aurais publié la version contenant ce petit correctif.

[FileCity]

Pour faire suite et clore mon intervention, dans ce cas de mise en veille, si cela est absolument nécessaire, je recommanderais un ordinateur portable, si possible. De ce fait, un portable ayant son propre UPS intégré par la pile, ce genre de problème ne devrait pas ce produire. Mon PC est allumé 24/7 et l’électricité est très peu chère au Québec mais j'en conviens que ceci n'est pas la solution pour tous.

@gawindx, bravo pour ton développement sous WinNUT, tu redonne confiance en ce produit. Le client NUT pour Windows original est très difficile à intégrer par manque de développement depuis bien des années... Merci pour ton travail. Si je peux aider ne te gêne pas, j'ai un 2e Pi avec NUT qui peut servir de serveur de test avec une VM, si nécessaire. J'ai aussi écris quelques scripts en BASH pour gérer et automatiser certains trucs sur le serveur NUT, si tu as un repository je peux les partager, on ne sais jamais, ça pourrait être utile à quelqu'un.

[Dim3333]

@FileCity J'avais un portable avant de passer au mini-PC. J'ai changé car :

• batterie du portable HS
• bruit (mini PC derriere l'ecran = pratiquement silencieux)
• ecran evolutif independamment du PC
• PC evolutif independamment de l'ecran :)
• rapport prix/performance plus avantageux (selon moi)

Sinceres salutations aux Quebecois !

@gawindx Mon serveur domotique (sous Domoticz) me permet deja de monitorer l'etat de mon onduleur. Je rejoins FileCity, bravo pour avoir repris le developpement de WinNut et bon courage pour les futures versions.

[gawindx]

Merci pour votre soutien, ça représente pas mal de boulot au final (surtout pour un non professionnel) mais c'est assez plaisant de voir que le projet commence à être pas mal utilisé.

La modification est faite pour l'entrée et la sortie de veille, l'information sera dans les logs et aussi affiché dans les événements récents de la GUI.

Au moins ce genre de cas sera plus facile à détecter à l'avenir.

Par contre, si je ne dis pas de bêtises, le client WinNUT officiel est plutôt celui ci :

Celui que j'ai repris est à l'origine un projet Sourceforge sous AutoIT et qui ressemblait plutôt à ça :

Et comme le projet était ancien, ça à déjà été une belle galère de le faire fonctionner...

@FileCity Je prends note pour les essais, mais je pense que ça sera peut-être plus pour les versions beta (surtout quand je pourrais passer au développement du service Windows). Et pour les script, pourquoi ne pas les héberger et les partager via gists, l'avantage c'est que ça peux aussi te servir de sauvegarde via ton compte GitHub

Et j'ai aussi fait quelque recherches pour une implémentation plus fidèle du protocole, au final je suis pas si mal que ça, la façon de procéder n'est pas la même mais la façon de dialoguer est assez proche : nutclient.cpp officiel

[joelnn]

I have the same issue, I guess. I installed 2.0.7710, this is the first time I'm trying WinNUT. When I try to start WinNUT-client, I see the tray icon for about 5 seconds, and then it closes (crashes).

The Windows Event Viewer shows this:

Faulting application name: WinNUT-client.exe, version: 2.0.7710.35902, time stamp: 0x6022daec Faulting module name: KERNELBASE.dll, version: 10.0.19041.804, time stamp: 0xb610d74d Exception code: 0xc000041d Fault offset: 0x0012a8b2 Faulting process id: 0x5bc8 Faulting application start time: 0x01d703b40d8b3d97 Faulting application path: C:\Program Files (x86)\WinNUT-client\WinNUT-client.exe Faulting module path: C:\WINDOWS\System32\KERNELBASE.dll Report Id: d2a48fe8-dab6-406a-9c4b-c25c633d2c1f Faulting package full name: Faulting package-relative application ID:

Fault bucket 1700061056258444291, type 5 Event Name: CLR20r3 Response: Not available Cab Id: 0

Problem signature: P1: WinNUT-client.exe P2: 2.0.7710.35902 P3: 6022daec P4: System P5: 4.8.4300.0 P6: 5f7e6395 P7: 2dc7 P8: 11f P9: System.Security.Security P10:

[gawindx]

Okay, I reopen the subject

After some research on the elements that you provided to me, it is possible that this is a problem of permission on the base of registers.

To remove this hypothesis, can you check if the keys have been correctly created (take a look at this link, I indicated the location of the key in the registry).

Another possibility is a problem with the encryption function added in the latest version. But before going any further I await your return on the issue of the registry.

[gawindx]

@joelnn, Little question, I am trying to find a workaround and logged a possible unhandled exception (so far without much success) but I realize that, in the windows logs, when winnut crashes I have:

• an "Application Error" event which contains the type of information you sent me
• A ".NET Runtime" event which contains much more information concerning the location of the error in the source code of the software.

Do you also have this information (and in this case I would be very interested if you communicate it to me) or is it only due to my development environment?

[joelnn]

@gawindx yes I have a .NET Runtime event as well:

Application: WinNUT-client.exe Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: System.Security.SecurityException at System.Diagnostics.EventLog.FindSourceRegistration(System.String, System.String, Boolean, Boolean) at System.Diagnostics.EventLog.SourceExists(System.String, System.String, Boolean) at System.Diagnostics.EventLogInternal.VerifyAndCreateSource(System.String, System.String) at System.Diagnostics.EventLogInternal.WriteEvent(System.Diagnostics.EventInstance, Byte[], System.Object[]) at System.Diagnostics.EventLog.WriteEvent(System.Diagnostics.EventInstance, System.Object[]) at System.Diagnostics.EventLogTraceListener.TraceEvent(System.Diagnostics.TraceEventCache, System.String, System.Diagnostics.TraceEventType, Int32, System.String) at System.Diagnostics.TraceSource.TraceEvent(System.Diagnostics.TraceEventType, Int32, System.String) at Microsoft.VisualBasic.Logging.Log.WriteException(System.Exception, System.Diagnostics.TraceEventType, System.String, Int32) at Microsoft.VisualBasic.Logging.Log.WriteException(System.Exception, System.Diagnostics.TraceEventType, System.String) at WinNUT_client.My.MyApplication.MyApplication_UnhandledException(System.Object, Microsoft.VisualBasic.ApplicationServices.UnhandledExceptionEventArgs) at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.raise_UnhandledException(System.Object, Microsoft.VisualBasic.ApplicationServices.UnhandledExceptionEventArgs) at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.OnUnhandledException(Microsoft.VisualBasic.ApplicationServices.UnhandledExceptionEventArgs) at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.OnUnhandledExceptionEventAdaptor(System.Object, System.Threading.ThreadExceptionEventArgs) at System.Windows.Forms.Application+ThreadContext.OnThreadException(System.Exception) at System.Windows.Forms.Control.WndProcException(System.Exception) at System.Windows.Forms.Control+ControlNativeWindow.OnThreadException(System.Exception) at System.Windows.Forms.NativeWindow.Callback(IntPtr, Int32, IntPtr, IntPtr)

This seemed like maybe it was an exception with logging itself after the error has happened (whatever the error is), so I didn't post it before. But it is hard to read these things. Hope it helps.

Regarding the registry, I didn't find any registry key there at all. I did a search of the whole registry for "WinNUT" and all I found was some .NET assembly information under another key. I was looking for the registry settings before since it seemed to be recommended to delete them and retry, but as I say, I couldn't find anything. Uninstall/reinstall also did not help.

To be honest, NUT was too advanced for my simple use, I switched back to apcupsd. So if you would like to set this issue aside for now, that would be fine with me.

[gawindx]

it helps a little bit, and indeed it seems to come from the log ...

The ironic part is that it seems to come mainly from the log functions used to trace the unmanaged exceptions of the application ....

Can you test the following version and tell me what it gives: Test version Winnut

If you encounter an exception, you will have a popup with a clearer message of the error encountered - Winnut will always close but this will allow you to have clearer information

The problem is that you are not the only one to have encountered this behavior (at least 2 so far) and I would like to understand what gets stuck before too many people encounter it.

Afterwards, if it doesn't work out better like that, we'll give up, but I think it may spoil me later.

[joelnn]

Sure here is the error dialog:

Fyi there is still no registry key after launching this version. And this time nothing appears in the Event Viewer.

[gawindx]

Well, that doesn't teach me much BUT it teaches me that I can recover information well during an unhandled exception.

I'm going to dig deeper into this because I think I can get a lot more information (maybe even create an interface to more easily generate a bug report or something similar).

I also tested on a laptop and it seems to be affected by this problem, so I will be able to debug it.

If you agree, I will submit the corrected version to you for testing before publication.

[joelnn]

Sure I'm happy to try the pre-release version.

[gawindx]

Finally, it will not be necessary to perform a test, the error was quite easy to resolve. I took the opportunity to implement an interface allowing me to generate a bug report containing the maximum amount of information needed, so as to have less trouble in the future.

[gawindx]

The new version is available: Winnut v 2.0.7721