Nistune Forums

Hi Matt,
I was running 0.10.17 from memory when I noticed the lefthand list was all out of wack.

then performed an overtop install of 0.10.19.
loaded a cr31 addy and stock bin.
clicked through all the new flashy icons across the top from left to right when the app crashed. I got to the input tracer window when it crashed.

W7 64.
nis 0.10.19

I suspicious that this only happens after the first instance of a new version being automatically executed after installation (when the installation option is ticked to start nistune after install and install drivers).
I tried to replicate but of course it doesn't happen the second time around.

Hi Matt,
Some new crash logs from last night at WSID.
At the end of my teather on this.. need a line here.

Nistune seems to crap out at varying points and intermittently. The consult drops during a run and then crashes when I try to end the log recording, lose the whole bloody lot and I only have 10-12 seconds of critcal log to work off thats unretreivable .. gone.

Why does the MAF voltage recording keep going after rpm signal stops for some period, Injection timing goes off the scale, Knock count for an ECU with no knock board record knock count?

Is their a way nistune could save the log as it goes so the log isn't affected after a crash?

Any help appreciated
Simon

Is an issue with Type 1 + Innovate MTS + Logger going at the same time. Is difficult to repeat but I've seen the same crash here. Try and repeat this weekend.

When disconnecting the logger still records now waiting for a reconnect

1. MAF voltage is still logged since last value is still used (RPM last value seen probably 0)
2. Injection time may be a half read value which is why it went off scale
3. Knock count will increase in the Type 1 firmware when no knock board is installed. ECU shows the knock line high so the firmware keeps on counting it even though knocking

Log files are recorded as they go. They should be complete. They only get deleted when you hit stop and respond yes to quit. If you are finding only a partial log file I can increase the frequency of log 'flushes' where it writes from PC memory to the file. Increasing flush frequency slows down logging to it has to be spaced in decent intervals

Today the '>>>' button didn't show LC-1's AFR in input tracer. Had to play log at normal speed for it to show in the input tracer window.

since 0.10.19 install, nis not recognizing the type 1 board when click consult, then I check config, try it again, it works... don't figure. happens on 2 laptops.
and almost always can't find the LC-1 on the first or second attemp, on belkin usb serial convertor. Any idea on this?

I dont see problem here with LC-1 not connecting first time. Been using it Saturday whilst trying to repeat crash issue (using S13 CA18DET ECU + LM1 + Logging) but was unable to repeat the crash unfortunately. Will keep trying

When first powering on ECU it may take several seconds for PC to 'see' the USB device before Nistune can connect to it. If Nistune doesnt see a Type 1 board it will then scan 'COM' ports for a consult cable and try and connect to other boards. Opening File > Config should make no difference for a Type 1 board, but it will do a rescan of COM port

Also looked at the change log to the USBMain file which does Type 1 and no significant changes have been made (apart from scanning other COM ports) to this file that I can see related to this issue

I would need a log of you trying to connect to the Type 1 board (say 3 x in row) and then File > config and then Type 1 again

Strange with the fast AFR trace. Just tried one here and worked. Can I have your log file?

Does it do it on your machine with my log file (below) on Innovate main setting in File > Config

also the page scroll across >> only steps in small increments, it use to scroll log to the right, and now the >>> is working. Argghhhh .
Have you changed the functions?

I've attached some debugs, I can't recall if they include the conection issues as I tried another latop and even turn debug off to see if it would reduce sporatic disconnects.

btw, nis displays all sorts of file open type errors when recovering from hibernation or standby. I understand it is not a great idea that these power management modes be used but it happened due to the battery on my spare lappie depleting unexpectedly.

also the page scroll across >> only steps in small increments, it use to scroll log to the right, and now the >>> is working. Argghhhh

this is reported in the 0.10.19 thread and fixed already. I'll put out another version soon. Deleted the wrong buttons in the log player. Use the mouse in the interim on the scroll bar

Okay I'll try the opening (log player active) from hybernate as a new issue.

Matt,
Attached is another log of consult problems. byte 25 not written, disconnects, crashed at the end.
some of the consult issues even happened when the engine wasn't running.
Hopefully it leads us somewhere.

btw, refering to romchips post on logplayer inconsistency, seeing the same thing when opening a bin, using the 'save as' function, then close nistune, reopen nistune, the previous file gets opened instead.

KR
Sime

Unfortunately the log files posted here dont indicate where the crash is coming from. Normally these are useful to find what the software is doing but when the application has a crash the last log buffer is normally not written to disk to find out what happened at the end

I've been investigating crashes for the last month and suggest following the guide here. Just need to type in drwtsn32 -i into the command window to enable Dr Watson debug logging. This will save the log details and exact location of the crash to a folder. Please email those through as these from looking at the ones here contain a lot more information with the exact line of code where the crash is triggered

viewtopic.php?f=5&t=362&p=17283

Dr Watson is not a feature in Vista or Windows 7 anymore.

Windows error reporting does however have some nistune entries..

Do you want this log ?

I didnt look into it with Vista/7 but if it generates the same kind of log output then if you can find where its located that would be helpful

Administrative Tools > Event Manager > Application Events

You should see crash events in here but I'm not sure if the logs go there. Normally they go to microsoft. Dr Watson lets you keep all the information locally. I'll have to look into those operating systems

So far I've tracked down three different types of crash on my XP laptop over the last month from 0.10.17-19
(a) Close table window (put some fixes in)
(b) Close log player window (OnLogClose() crash but cannot repeat on bench). Something to do with something accessing a data string whilst another thing is using it.
(c) File > Config display caused crash

26/05/2012 2:09 PM Application Error Faulting application name: Nistune.exe, version: 1.0.0.1, time stamp: 0x4fbf53e5
Faulting module name: Nistune.exe, version: 1.0.0.1, time stamp: 0x4fbf53e5
Exception code: 0xc0000005
Fault offset: 0x0004e17b
Faulting process id: 0xc04
Faulting application start time: 0x01cd3b490f3f1224
Faulting application path: C:\Program Files (x86)\Nistune\Nistune.exe
Faulting module path: C:\Program Files (x86)\Nistune\Nistune.exe
Report Id: 6ff63af6-a73c-11e1-9a4e-001cc4360bf2

this is one of the entries. is this what your after?

I have new PC for my job with Windows 7 Entreprise 64bits and 0.10.19/0.10.20 versions crash when trying to access the configuration menu.
Log attached.

0.10.13 doesn't crash when doing so.

What does happen ?

EDIT: 0.10.14, 0.10.15 and 0.10.17 crash the same way. I don't have other setup versions.
Btw, why do I get such message?:
14:00:42.576 Warning - MTS OCX is not registered. Innovate wideband will not be available
I re-installed Logworks3 and both mts.dll and mtssdk.ocx are in the Nistune prg directory

Strange, its saying there is a bunch of COM ports detect in that log. I'm guessing you dont ever get in to the File - config menu on that machine at the moment. Okay so changes between 0.10.13 to 0.10.14 may be responsible but its only on that machine

How many COM ports show up on that machine inside LogWorks3?

14:00:42.576 Warning - MTS OCX is not registered. Innovate wideband will not be available

Nistune looks to see the Innovate OCX is registered before it attempts to use it. Normally they are registered by LogWorks3 on installation using REGSVR32. You can use that command line program to manually register DLLs also

I re-installed Logworks3 and both mts.dll and mtssdk.ocx are in the Nistune prg directory

The MTS.DLL should not be in the Nistune folder anymore. It is not included with later installations. I dare say going backwards during installations has put the file back from an older version. It may be related to the crash issue due to incompatible DLL versions being on the machine (should only be one DLL in the LogWorks3 folder)

At this point I would suggest uninstall Nistune to clean out those files on that machine and then install the latest version. After doing this uninstall/reinstall LogWorks3 so the MTS DLL is registered again correctly

Another way of testing DLL registration is with the SDK 'VB sample' test code which uses the OCX in the same way as Nistune. If a bad DLL registration causes Nistune to crash it will probably do the same to the sample app
http://www.innovatemotorsports.com/support.php