[WIN32] Crash protection, welke methode lijkt jullie beste ?

[TheBlasphemer]

Ik ben bezig aan een plug-in voor MSN die nogal wat low-level doet. Hooken, patchen, je verzint het zo gek nog niet of je kunt er hele leuke functies mee maken
Echter zodra MSN update, wil het nog wel eens voorkomen dat er wat veranderd, een search-routine verkeerde offset vind, en het hele zootje crashed.
Nu wil ik graag een soort beveiliging inbouwen dat als MSN crashed de gebruiker hiervan op de hoogte stelt, en duidelijk uitlegt dat het best kan dat dit niet de schuld van MSN is, en dat ze eerst moeten proberen zonder mijn plugin. uiteraard ook duidelijk instructies hoe je tijdelijk disabled, en/of uninstalled.

Ik heb zo snel drie methoden weten te bedenken, maar aan elke methode kleven voor- en nadelen, en ik ben er niet helemaal zeker van welke methode nu het beste is.
Daarom graag jullie meningen over de volgende methoden:

• Methode 1: Bij laden van plug-in wordt een extra exe gestart, die constant MSN in de gaten houdt. Als MSN weg is, laat ie de foutmelding zien. plug-in zelf hooked PostQuitMessage, en als die aangeroepen wordt sluit die de controle-exe, zodat er geen bericht wordt weergegeven bij een nette afsluiting
  Grootste nadeel van deze methode is dat er wel constant een extra programma in de achtergrond draait als MSN draait, en gebruikers worden hier vaak paranoie over.
• Methode 2: Bij laden van de plug-in wordt een reg-key gezet. PostQuitMessage wordt gehooked, and als die wordt aangeroepen wordt de reg-key weggehaalt. Als de plug-in opstart en de reg-key is niet blanco, dan wordt de melding weergegeven, met mogelijkheid om de plugin niet door te laden. Nadeel is dat de gebruiker pas de volgende start een foutmelding krijgt, en niet op de hoogte wordt gesteld als MSN bijv stilletjes crashed.
• Methode 3: Bij laden van plug-in wordt een extra DLL geladen. bij PostQuitMessage wordt er in die DLL de functie Unlock() aangeroepen. Als de DLL wordt uitgeladen, en Unlock is niet aangeroepen, start deze een extra programma op dat de foutmelding weergeeft. In de meeste crash-gevallen worden DLLs alsnog netjes ge-unload. Nadeel is dat onder sommige omstandigheden de DLL niet goed wordt geunload.

Wat denken jullie hiervan?
Ikzelf vindt methode 3 het mooiste klinken, vooral omdat de nadelen van Methode 1 en 2 veel zwaarder zijn van het nadeel van methode 1
Ik zit eventueel ook te denken aan Methode 3 en 2 samen (dus als methode 2 de crash vind, doet die de foutmelding. Anders wordt methode 3 ingeschakelt.)

[Verwijderd]

TheBlasphemer schreef op zondag 12 maart 2006 @ 01:08:
Ik ben bezig aan een plug-in voor MSN die nogal wat low-level doet. Hooken, patchen, je verzint het zo gek nog niet of je kunt er hele leuke functies mee maken
Echter zodra MSN update, wil het nog wel eens voorkomen dat er wat veranderd, een search-routine verkeerde offset vind, en het hele zootje crashed.
Nu wil ik graag een soort beveiliging inbouwen dat als MSN crashed de gebruiker hiervan op de hoogte stelt, en duidelijk uitlegt dat het best kan dat dit niet de schuld van MSN is, en dat ze eerst moeten proberen zonder mijn plugin. uiteraard ook duidelijk instructies hoe je tijdelijk disabled, en/of uninstalled.
...

Je kan er beter voor zorgen dat je plugin 'certified' is voor MSN versie x.x

code:

if (msn versie = 'x.x.x) then
  load plugin
else
  don't load plugin
end if

of

code:

if (msn versie = 'x.x.x) then
  ok, do it
else
  do nothing
end if

[ Voor 10% gewijzigd door Verwijderd op 12-03-2006 01:16 ]

[TheBlasphemer]

Verwijderd schreef op zondag 12 maart 2006 @ 01:15:
[...]

Je kan er beter voor zorgen dat je plugin 'certified' is voor MSN versie x.x

code:

if (msn versie = 'x.x.x) then
  load plugin
else
  don't load plugin
end if

of

code:

if (msn versie = 'x.x.x) then
  ok, do it
else
  do nothing
end if

Is serieus te-veel werk Ze komen tegenwoordig zo verrekte vaak met nieuwe versies, dat ik dan elke week wel weer een patch moet uitbrengen. Gebruikers worden het dan ook zat elke keer te updaten Daarom maar gekozen om zoveel mogelijk proberen de toekomst te voorspellen, en goed nadenken of bepaalde byte-patterns intact zullen blijven in versies (en ook naar oude versies kijken enzo), en dan proberen functies te schrijven die (mits ze niet TE veel updaten) gewoon blijven werken

[Dricus]

Er zijn een aantal dingen die je volgens mij gewoon in de code van je plugin kunt doen:

• Exception handling in elke functie. De exception handlers kun je dan zo maken dat de gebruiker een nette foutmelding krijgt, MSN netjes afgesloten wordt, eventueel je plugin gedisabled word, en wat je al niet meer zou willen.
  Als je die exception handling echt goed opzet, kun je ook een stack-trace maken die de gebruiker dan naar jou kan emailen .
• Error checking op Win32 API functies (en op je eigen functies natuurlijk). Bijna alle Win32 functies geven een resultaat terug, of via hun return waarde, of via een GetLastError code of op een andere manier.
• Voor exceptions die buiten je code optreden (bijvoorbeeld als gevolg van "mislukte" patches) zou je eens kunnen kijken in de MSDN Library naar de SetUnhandledExceptionFilter functie.

Dit zijn eigenlijk gewoon basistips voor het schrijven van robuuste code. Volgens mij moeten de meeste van de problemen waar je tegenaan loopt hiermee wel op te lossen zijn.

[TheBlasphemer]

MrHuge schreef op zondag 12 maart 2006 @ 09:46:
Er zijn een aantal dingen die je volgens mij gewoon in de code van je plugin kunt doen:

• Exception handling in elke functie. De exception handlers kun je dan zo maken dat de gebruiker een nette foutmelding krijgt, MSN netjes afgesloten wordt, eventueel je plugin gedisabled word, en wat je al niet meer zou willen.
  Als je die exception handling echt goed opzet, kun je ook een stack-trace maken die de gebruiker dan naar jou kan emailen .
• Error checking op Win32 API functies (en op je eigen functies natuurlijk). Bijna alle Win32 functies geven een resultaat terug, of via hun return waarde, of via een GetLastError code of op een andere manier.
• Voor exceptions die buiten je code optreden (bijvoorbeeld als gevolg van "mislukte" patches) zou je eens kunnen kijken in de MSDN Library naar de SetUnhandledExceptionFilter functie.

Dit zijn eigenlijk gewoon basistips voor het schrijven van robuuste code. Volgens mij moeten de meeste van de problemen waar je tegenaan loopt hiermee wel op te lossen zijn.

Exception handling doe ik niet zo veel aan, omdat ik meer met basic C doe dan met C++ specifieke dingen (dus try en catch blokken zijn in die gevallen niet zo handig ).
Alle Win32 functies check ik natuurlijk wel of ze goed gegaan zijn
Waar ik inderdaad meer op doelde waren mislukte patches. Ik kende die functie van exception handling nog niet en zal meteen eens kijken hoe die werkt Lijkt me een stuk simpeler dan die ingewikkelde methodes die ik zelf had bedacht
Bedankt voor de tip!

EDIT: En ken ik jou niet van msgplus forums ? met die leuke obelix avatar ?

[ Voor 3% gewijzigd door TheBlasphemer op 12-03-2006 12:11 ]

[MSalters]

Als je bij exception handling aan C++ denkt en niet aan C, dan is het misschien een goed idee om eens een advanced Win32 boek te lezen.

Een Access Violation is de meest gangbare exception als je low-level iets fout doet. Initieel is het ene processor trap, die door Win32 Structured Exception Handling wordt opgevangen. Indien je programma daar niet op reageert, dan wordt je programma afgesloten.

Overigens zegt PostQuitMessage niet alles - atexit() processing kan daarna nog problemen veroorzaken.

[TheBlasphemer]

MSalters schreef op zondag 12 maart 2006 @ 12:18:
Als je bij exception handling aan C++ denkt en niet aan C, dan is het misschien een goed idee om eens een advanced Win32 boek te lezen.

Meeste Win32 kennis die ik heb komt uit MSDN
Ik ga binnenkort wel weer bestelling bij Amazon doen, dus is er nog een boek dat je kan aanraden ?
En zou je me evt op dit moment al kunnen vertellen wat voor exception handling je het over hebt ?

Een Access Violation is de meest gangbare exception als je low-level iets fout doet. Initieel is het ene processor trap, die door Win32 Structured Exception Handling wordt opgevangen. Indien je programma daar niet op reageert, dan wordt je programma afgesloten.

Klopt, maar soms met mislukte patches kan het wel eens voorkomen dat je de verkeerde commandos patched, of middenin ASM commandos patched, en dan kunnen er ook hele leuke andere fouten ontstaan

Overigens zegt PostQuitMessage niet alles - atexit() processing kan daarna nog problemen veroorzaken.

Klopt ook, maar PostQuitMessage wordt door MSN aangeroepen als de gebruiker aangeeft te willen afsluiten, dus dat leek me een mooie plek om de anti-crash methodes druit te halen

[Dricus]

TheBlasphemer schreef op zondag 12 maart 2006 @ 12:08:
EDIT: En ken ik jou niet van msgplus forums ? met die leuke obelix avatar ?

Yups, dat klopt .

Enneeh, zoals gezegd: exception handling is niet voorbehouden aan C++, je kunt het ook met gewoon C gebruiken. In jouw geval zou trouwens Structured Exception Handling wel een goede optie kunnen zijn.
Exception handling is geen heel eenvoudige materie, maar als je het eenmaal goed hebt opgezet in je applicatie, dan ga je er heel erg veel plezier van hebben.

[MisterData]

Je kunt met __try en __except gewoon access violations opvangen vziw