When posting a KPro problem with your vehicle, please include:
- Serial No: 4900
- Make/Model: 2003 Acura RSX-s
- Product: K-Pro
With the latest version of K-Manager 1.2.3.3, I get a crash on startup (before the screen is even created).
I'm running Windows 2000 Pro, 1G ram, P4-1.8Ghz, Dell Inspiron 8200. Previous version of KManager worked fine.
KManager.exe C:\Program Files\KManager\KManager.exe N/A N/A Binary was not built with debug information. 1 1.02.3.3 2/25/2008 1:09 PM 00400000-00874B6E [1996] KManager.exe: Native
There is a null ptr exception at offset 0x00872CF0.
ESI 00000000
EAX 7C596A05
EDI 7C596A0A
00872CD9 FF 95 00 04 00 00 call dword ptr [ebp+400h]
00872CDF C7 85 DA 4D 00 00 01 00 04 02 mov dword ptr [ebp+4DDAh],2040001h
00872CE9 8B C7 mov eax,edi
00872CEB 2B C6 sub eax,esi
00872CED 83 E8 05 sub eax,5
00872CF0 C6 06 E9 mov byte ptr [esi],0E9h
00872CF3 89 46 01 mov dword ptr [esi+1],eax
Is there any logging I can turn on to provide more info?
Crash at startup with 1.2.3.3
I do have internet connection when I launch. I backed down to 1.2.3.1 and it works again. Then I upgraded to the latest and no dice.
Has the target platform/architecture been changed in recent version? I'm able to do a dumpbin on the version that works and it shows all the symbols and imports. On the latest, I get the result below, which shows it's not even recognized at a complete executable (unless you guys are being crafty and doing a 2 stage load and encrypting/compressing the main executable). When I run it under strace, I don't even hit a single system call before it exits from a first chance exception.
My gut says it has to do with me running Win 2K pro still.
-----------
Microsoft (R) COFF/PE Dumper Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file KManager.exe
File Type: EXECUTABLE IMAGE
DUMPBIN : warning LNK4078: multiple '.text' sections found with different attributes (E0000020)
Section contains the following imports:
kernel32.dll
86F1EE Import Address Table
0 Import Name Table
0 time date stamp
0 Index of first forwarder reference
0 LoadLibraryA
0 GetProcAddress
0 VirtualAlloc
0 VirtualProtect
0 VirtualFree
0 GetModuleHandleA
Summary
193000 .text
2E1000 .text
Has the target platform/architecture been changed in recent version? I'm able to do a dumpbin on the version that works and it shows all the symbols and imports. On the latest, I get the result below, which shows it's not even recognized at a complete executable (unless you guys are being crafty and doing a 2 stage load and encrypting/compressing the main executable). When I run it under strace, I don't even hit a single system call before it exits from a first chance exception.
My gut says it has to do with me running Win 2K pro still.
-----------
Microsoft (R) COFF/PE Dumper Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file KManager.exe
File Type: EXECUTABLE IMAGE
DUMPBIN : warning LNK4078: multiple '.text' sections found with different attributes (E0000020)
Section contains the following imports:
kernel32.dll
86F1EE Import Address Table
0 Import Name Table
0 time date stamp
0 Index of first forwarder reference
0 LoadLibraryA
0 GetProcAddress
0 VirtualAlloc
0 VirtualProtect
0 VirtualFree
0 GetModuleHandleA
Summary
193000 .text
2E1000 .text
It seems these last two updates are for preventing reverse engineering of your product, at the sacrifice of wider platform compatibility.
The new releases don't take too kindly to attaching with a debugger or memory searching tools. I guess I'll be sticking with KManager 1.2.3.1 until such a time that an API is provided for accessing the sensors from my own apps.
Even just a simple TCP/IP socket that could barf out the sensor values would be ideal, without the risk of exposing any trade secrets. Just an idea.
Still a huge fan of what you have accomplished with the K-Pro.
The new releases don't take too kindly to attaching with a debugger or memory searching tools. I guess I'll be sticking with KManager 1.2.3.1 until such a time that an API is provided for accessing the sensors from my own apps.
Even just a simple TCP/IP socket that could barf out the sensor values would be ideal, without the risk of exposing any trade secrets. Just an idea.
Still a huge fan of what you have accomplished with the K-Pro.