Beiträge von Jonathan

Zitat von RGH

Der Kommentar einer Headerzeile beginnt mit dem letzten Semikolon der Zeile und darf daher selber kein Semikolon enthalten. Dies ermöglicht die Verwendung vom Semikolon im Header selbst. Der Fehler liegt also hier im Header.

Gruß
Roland

Ah, ok, dann sollte der Fehler ja recht leicht zu beheben sein. Vielen Dank!

Gruß
Jonathan

Zitat von p. specht

Super

Frage ("Ein Narr kann mehr fragen als 10 Weise beantworten..."): Gibt es eine Möglichkeit, das verwendete Übergabeverfahren solcher Zusatz-DLL irgendwie automatisch zu erkennen? Gibt's eine Art Marker, ähnlich wie in Windows-Programmen die Anfangszeichen "MZ" nach Mark Zbikowski?

Aus einer ähnlichen Anfragebeantwortung werde ich jedenfalls nicht schlau: http://stackoverflow.com/questions/4162…third-party-dll

Leider nicht wirklich - der Unterschied zwischen CDECL und STDCALL ist z.B. nur, dass bei CDECL der Aufrufer den Stack hinterher saubermacht, und bei STDCALL die aufgerufene Funktion selbst das tut. Wenn du eine Möglichkeit findest, zu erkennen, ob der Stack bereits sauber ist, oder nicht, kann man das natürlich auch automatisch machen.

Gruß
Jonathan

So... Zum Testen einer anderen XProfan-Version bezüglich Gleitkommagedöns bin ich leider noch nicht gekommen, dafür hab ich aber ein nettes Stück Code für euch

Declare callbackCDECLtoSTDCALL#, cbcode$
cbcode$ = "55 89 E5 83 EC 28 C7 45 F4 55 55 55 55 8B 45 08 89 04 24 8B 45 F4 FF D0 83 EC 04 C9 C3 90 90 90 "
Dim callbackCDECLtoSTDCALL#, @Len(cbcode$) / 3 + 1
WhileLoop 1, @Len(cbcode$) - 2, 3
  Byte callbackCDECLtoSTDCALL#, (&loop - 1) / 3 = @Val("$" + @Mid$(cbcode$, &loop, 2))
EndWhile
WhileLoop 0, @SizeOf(callbackCDECLtoSTDCALL#) - 1 - 3
  If @Long(callbackCDECLtoSTDCALL#, &loop) = $55555555
    Long callbackCDECLtoSTDCALL#, &loop = @ProcAddr("XProfan_callback_func", 1)
  EndIf
EndWhile




'Beispiel
@External("CDECL-DLL.dll", "FunktionDieEinCallbackInCDECLHat", callbackCDECLtoSTDCALL#)

Konvertiert einen CDECL-Call in einen STDCALL-Call, damit man auch DLLs, die CDECL verwenden, XProfan-Callback-Funktionen geben kann. Der Assembler-Code macht das momentan aber nur für Calls mit bloß einem Argument.

Gruß
Jonathan

Zitat von ts-soft

Ich denke mal, die DLL benötigt CDECL Convention, bei STDCALL wird wohl der Stack crashen.

Man gebe mir eine Wand. Genau so war es. Ich hab die Funktionen von Lua51.dll jetzt mit Wrappern versehen, die vorher in XProfan die Calling Convention umstellen und hinterher wieder zurück, jetzt funktioniert es. Vielen Dank!

Zitat von Volkmar

Ich kann hier nur raten, ich kenne Lua nicht. Erst mal fällt mir auf, dass die Bereichsvariable mainLState# nicht gedimmt ist. Du weist der dann zwar in Zeile 7 eine andere Adresse zu, aber ich glaube mich daran zu erinnern, dass ein Bereich trotzdem in der entsprechenden Größe gedimmt sein sollte.

Nee, daran lag es nicht - XProfans Bereichs-Typ ist einfach nur ein 32-Bit-Pointer, solange man den Bereich nicht dimensioniert (bei Dimensionierung wird er noch mit ein paar Zusatzdaten versehen). Ich hab den Typ nur der Übersicht halber gewählt, damit ich weiß, dass das ein Pointer ist, was da drin ist - ich hätte genauso gut einen Integer nehmen können. Aber vielen Dank auch an dich, dass du dir darüber Gedanken gemacht hast

Gruß
Jonathan

Hallo,

für ein Projekt, in dem ich dynamische Typisierung, Metatabellen und durch den Nutzer änderbaren Code brauche, wollte ich meinem XProfan-Programm einen Lua-Interpreter unterschnallen. Ich habe mir also Lua51.dll und Lua5.1.dll aus meiner Lua-Installation genommen und diese mit folgendem Code auszuführen versucht:

Declare mainLState#, luadll&, luaerr&
CLS


luadll& = @ImportDLL("Lua51.dll", "")




mainLState# = luaL_newstate()
Print lua_checkstack(mainLState#, 20)
Print luaL_loadfile(mainLState#, "test.lua")
Print lua_pcall(mainLState#, 0, 0, 0)
Print lua_close(mainLState#)


WaitInput
FreeDll luadll&

Ich bekomme jedoch Programmabstürze (Write auf 0x00000000) bei fast allem, was ich mit dem Lua-State machen will. Ohne lua_checkstack crasht es sogar schon bei lua_pcall. Ich kann nichtmal einen Lua-State öffnen und direkt wieder schließen - selbst das crasht bei lua_close. Langsam bin ich etwas verzweifelt, da der selbe Code - nur in einer anderen Sprache - bei hunderten Leuten funktioniert, und nur bei mir zu seltsamen Crashes führt.

Was mache ich falsch?

Gruß
Jonathan

Produziert bei mir auf XProfan X2.1 leider nur Gleitkommaüberläufe... War da nicht mal was, wo wir das mit den Floats ausprobiert hatten?

Gruß
Jonathan

So... Gibt's von mir doch auch mal wieder was für diesen Thread. Lang ist's her.

Ich habe mir gestern ein kleines Framerate-Monitoring-Programm für DirectX-Spiele geschrieben, welches die Shared-Memory-Schnittstelle von "RivaTuner Statistics Server" (auch bekannt als "MSI Afterburner On-Screen Display Server") nutzt, und damit ein kleines Overlay ins Spiel zaubert. Das Programm berechnet die durchschnittliche Framerate, die Schwankung der Framerate, die Langzeit-Schwankung der Framerate, die durchschnittliche Schwankung der Framerate und die Minimale/Maximale Framerate. Dazu kann man die Messwerte in eine Datei aufzeichnen, um sie dann z.B. mit Gnuplot oder so graphisch darzustellen.

EDIT: Irgendwie knödelt mir die neue Forensoftware den ganzen Code in eine Zeile, entfernt also alle Zeilenumbrüche. Seltsam. Deshalb muss ich hier wohl leider einen werbeverseuchten Hoster nutzen...: http://www.file-upload.net/download-84909…_test.xprf.html

Falls es jemand gebrauchen kann... Viel Spaß damit. Den Code zum Anzeigen von Overlays sollte man da auch recht leicht rausfischen können, sodass man auch andere Sachen als Overlay in Spielen anzeigen kann.

Gruß
Jonathan

Hallo,

als ich eben die Konstante "SECTION_ALL_ACCESS" (Windows.ph) in einem Programm verwenden wollte, bekam ich von XProfan X2.1 folgende Fehlermeldung:

---------------------------XProfan Fehler---------------------------Klammern nicht ausgewogen: HMAPFILE&= External("kernel32.dll","OpenFileMappingA",$000F001F; '(STANDARD_RIGHTS_REQUIRED | SECTION_QUERY | SECTION_MAP_WRITE | SECTION_MAP_READ | SECTION_MAP_EXECUTE | SECTION_EXTEND_SIZE), 0, "RTSSSharedMemoryV2")Zeile  9 in C:\Users\Jonathan\Desktop\Stuff\RTSS_OSD\OSD_test.xprf: hMapFile& = External("kernel32.dll","OpenFileMappingA",$000F001F; '(STANDARD_RIGHTS_REQUIRED | SECTION_QUERY | SECTION_MAP_WRITE | SECTION_MAP_READ | SECTION_MAP_EXECUTE | SECTION_EXTEND_SIZE), 0, "RTSSSharedMemoryV2")

Der Fehler tritt auf, wenn ich folgenden Code ausführen will:

hMapFile& = ~OpenFileMapping(~SECTION_ALL_ACCESS, 0, "RTSSSharedMemoryV2")

Offensichtlich werden die in Windows.ph viel vorhandenen Kommentare hinter den Zeilen nicht korrekt herausgefiltert (vielleicht wegen dem Semikolon im Kommentar?).

SECTION_ALL_ACCESS = $000F001F; '(STANDARD_RIGHTS_REQUIRED | SECTION_QUERY | SECTION_MAP_WRITE | SECTION_MAP_READ | SECTION_MAP_EXECUTE | SECTION_EXTEND_SIZE);

Es wäre schön, wenn dieser Fehler behoben werden könnte. Als Workaround werde ich jetzt erstmal alle Kommentare aus den Header-Dateien entfernen.

Gruß
Jonathan

Soooo... Gestern habe ich dann mal rein aus Neugier Windows parallel auf die HDD neu installiert. Ergebnis: Lief, als wäre nie etwas gewesen. Auch DxDiag zeigte jetzt in der 32-Bit-Version die korrekte Menge VRAM an. Inzwischen habe ich den Verdacht, dass bei der alten Installation etwas mit den Windows Updates schief gelaufen ist, bzw. etwas in der falschen Reihenfolge installiert wurde. Bei einigen Updates, die DirectX betreffen, bin ich nämlich auf die Anmerkung "Dieses Update verursacht unter Umständen Appcrashes, der Fehler wird in einem anderen Update behoben" gestoßen, z.B. bei KB2505438.

Ich hoffe, das bleibt jetzt so.

Ich danke dir trotzdem vielmals für deine Hilfe!

Gruß
Jonathan

Puh... Auch ich habe gerade leider ziemlich wenig Zeit, in der Schule stehen gerade Klausuren an.

Ich werde das wohl erst in ein paar Tagen machen können, aber da es kein Virus ist, dürfte es auch nicht so drängen. Vielen Dank aber schonmal!

Gruß
Jonathan

Zitat von AHT;1001959

Da werde ich nicht weiterkommen - schade.

Hm, das ist doof. Ich habe aber das Gefühl, als würde der Deinstallationsmanager von Catalyst die Treiber-DLLs nicht entfernen und diese bei einer Neuinstallation nicht überschreiben - meinst du, du könntest mir helfen, noch einmal eine komplett saubere Installation von Catalyst hinzubekommen?

Gruß
Jonathan

Zitat von AHT;1001864

Und läuft immer noch nicht - richtig?

Leider ja.

Gruß
Jonathan

Zitat von AHT;1001857

Schau mal - richtig?
ASUSTeK Computer Inc. -Support- Drivers and Download P8Z77-V LX
Zur Not noch richtiges Betriebsystem einstellen.

Jep, da war ich vorhin auch - ist auch alles installiert und aktuell.

Gruß
Jonathan

Zitat von AHT;1001847

Um welches Gerät handelt es sich (Gerätetyp)?

Selbst zusammengestellter Computer. Die Spezifikationen stehen im ersten Post.

Gruß
Jonathan

Zitat von AHT;1001839

Nach einer aktuellen Version des Grafikkartentreibers im Netz suchen - oder eine ältere nehmen.

Ich habe bereits 12.x, 13.1 (mit der es definitiv mal lief), 13.4 (die auch mal lief), 13.11 und die neueste Beta ausprobiert... Überall das selbe Problem.

Gruß
Jonathan

Zitat von AHT;1001837

Dann passt das schon.
Schau mal auf der Homepage von Asus, ob es da Updates für das Gerät gibt. Installiere die Treiber von der Homepage für das Gerät.
Hilft das nicht, müsste man mit dem Grafikkartentreiber experimentieren.

Schau mal hier:

Code

Name der fehlerhaften Anwendung: fr-081.exe, Version: 0.0.0.0, Zeitstempel: 0x4db2b017
Name des fehlerhaften Moduls: atiu9pag.dll, Version: 8.14.1.6354, Zeitstempel: 0x528f6fc3
Ausnahmecode: 0xc0000005
Fehleroffset: 0x00006519
ID des fehlerhaften Prozesses: 0xd3c
Startzeit der fehlerhaften Anwendung: 0x01cee874979eb177
Pfad der fehlerhaften Anwendung: D:\Users\Jonathan\Downloads\fr-081\fr-081.exe
Pfad des fehlerhaften Moduls: C:\Windows\system32\[B][COLOR=red]atiu9pag.dll[/COLOR][/B]
Berichtskennung: d7dd6970-5467-11e3-b650-50465d64262a

Läuft da in der DLL was falsch, könnte das auch den Fehler in der ntdll erklären.

Es gibt nur ein Update für die Intel-iGPU, das mir bereits mit den Windows Updates installiert wurde. Außerdem ist die integrierte GPU sowieso deaktiviert. Wenn ich sie aktiviere, macht das jedoch auch keinen Unterschied, die Crashes bleiben.

Das mit der AMD-DLL klingt plausibel. Wie soll ich mit dem Treiber (zu dem die DLL ja gehört) experimentieren?

Gruß
Jonathan

Zitat von AHT;1001833

OK, Dateien können wieder weg.
Sieht nach Problemen mit dem Grafikkartentreiber oder der Karte aus.
Sind die Chipsettreiber korrekt drauf?

Die Chipsettreiber waren eigentlich das erste, was ich auf dem PC installiert habe - mit der Asus-Support-CD vom Motherboard. Lediglich die AI Suite hab ich weggelassen. Wie kann ich das prüfen?

Gruß
Jonathan

Stimmt, YourFault hatte ich schon mal ausprobiert... Ich sollte mir mal merken, dass das Programm praktisch sein könnte.

Eventlog bekommst du per PN.

Gruß
Jonathan

Zitat von AHT;1001819

Erklärung:
Der Ausnahmefehler 0xc0000029 kommt aus der ntdll.dll.
Die GetLastError API dürfte dir aus der Programmierung bekannt sein. GetLastError liest im Prinzip einen Wert aus dem Prozessspeicher aus, an dem der letzte Wert des Fehlers gespeichert wird, der beim Ausführen einer API entstanden ist. Siehe unter anderem auch hier: CreateFile function (Windows)

Einen zweiten Wert gibt es für die native API aus der ntdll.dll. Dieser Wert war beim Absturz 0xc0000029, das bedeutet:

Diese ganzen hexadezimalen Fehlercodes sind im Prinzip Zahlen, die auf Textausdrücke in einer DLL verweisen, die deren Fehlerbeschreibung angeben.

Da stand scheinbar im Speicher ein Wert, der Außerhalb eines gültigen Bereiches lag (ERROR_INVALID_UNWIND_TARGET ist der gleiche Fehler in der kernel32.dll). Wenn ich das richtig verstehe, sollte da als Ergebnis einer Prozedur zu einer ungültigen Adresse gesprungen weden: 5.2.1 Unwind Basic Considerations

Ah, danach habe ich auch bereits gesucht - ich habe die MSDN-Seite mit den Fehlercodes aber einfach nicht finden können. Die Scan-Ergebisse solltest du per PN erhalten haben.

Gruß
Jonathan