Ot-Attansic Ehternet Utility Error

On this P5B E (WinXP3) is the Attansic controller, comes with a diagnostic utility that
worked fine several years ago but now the executable mimo.exe terminates with

Assertion failed: This -- isOpened-=true,file D:\Aloha\mimo-a\src\WinRegistry cpp. line
529.


Reinstalling did not work, There is no folder like that on the install disk and
reinstalling the latest driver from the web gives same error. I cannot find the .cpp
file. Attansic may be out of businses.

Nice.

FUBAR,


Does any one have any idea what's happening, fix it ?

troop wrote:
On this P5B E (WinXP3) is the Attansic controller, comes with a diagnostic utility that
worked fine several years ago but now the executable mimo.exe terminates with

Assertion failed: This -- isOpened-=true,file D:\Aloha\mimo-a\src\WinRegistry cpp. line
529.


Reinstalling did not work, There is no folder like that on the install disk and
reinstalling the latest driver from the web gives same error. I cannot find the .cpp
file. Attansic may be out of businses.

Nice.

FUBAR,


Does any one have any idea what's happening, fix it ?

http://en.wikipedia.org/wiki/Assert

"...to reason about program correctness"

The software developer feels, that at line 529 in his Winregistry.cpp code,
that something should already be open. The ASSERT check is a check
done for logical correctness. It means the software developer
already did the "open" operation previously, and the item in question
should still be open, and it is not. Thus, the ASSERT, which checks
that the condition is true, has failed.

My guess would be, some key in a registry hive was open, and somehow, it is
now closed. It could be a logic error in the program, or that the item in
the registry never managed to be opened in the first place.

You could try re-installing the utility as "Administrator", and see if that helps.

You can also use one of the Sysinternals programs, and trace the execution of
mimo.exe and see the log of registry keys it is opening or attempting to open.
That in turn, may give a hint as to what part of the registry the program cannot
access to make changes.

Sysinternals Process Monitor.

http://technet.microsoft.com/en-ca/s.../bb896645.aspx

I've used ProcMon in the past, to diagnose a problem with the CMedia Mixer.exe
program for my sound card. I set up ProcMon to only trace events associated
with "Mixer.exe" and then attempted to open the custom mixer panel. I could see
registry operations being attempted, then the program exiting abnormally. Based
on the last registry key it was accessing, I was able to figure out that
another piece of sound hardware and its associated driver, had messed with the
registry keys, and that was upsetting Mixer.exe. Once I manually corrected the
registry, Mixer worked properly again. So you can use ProcMon to figure
out what registry operation may be upsetting a program. There is no guarantee
it is the *last* key accessed that is the problem. Since the program is
failing on an ASSERT, the registry key in question could have been opened
five minutes ago. ProcMon produces mounds of data, and when I fixed my problem,
I had to wade through about 100,000 entries until I found the interesting bits.

Also, Attansic didn't go out of business. I think they were bought out.
Attansic was a small fabless semiconductor firm, which was 25% owned by
Asus (at least initially). They made relatively small chips, doing things
like overclock controllers and the like. I wasn't really following the company,
but checked a press release when they were still a small company. Then, all of
a sudden, out pops a LAN chip, which was completely out of line for such a
small company (the gate count and complexity of the LAN chip, is much larger
than one of their previous chips). That was followed soon after, with the
company being bought out. They're owned by Atheros now. As to why Atheros
would want them, I haven't a clue.

http://www.reuters.com/article/idUSWNAS945320061023

Good luck,
Paul

In article , says...
http://en.wikipedia.org/wiki/Assert

"...to reason about program correctness"

The software developer feels, that at line 529 in his Winregistry.cpp code,
that something should already be open. The ASSERT check is a check
done for logical correctness. It means the software developer
already did the "open" operation previously, and the item in question
should still be open, and it is not. Thus, the ASSERT, which checks
that the condition is true, has failed.

My guess would be, some key in a registry hive was open, and somehow, it is
now closed. It could be a logic error in the program, or that the item in
the registry never managed to be opened in the first place.

You could try re-installing the utility as "Administrator", and see if that helps.

You can also use one of the Sysinternals programs, and trace the execution of
mimo.exe and see the log of registry keys it is opening or attempting to open.
That in turn, may give a hint as to what part of the registry the program cannot
access to make changes.

Sysinternals Process Monitor.

http://technet.microsoft.com/en-ca/s.../bb896645.aspx

Thank you. I do not want to trace the thing that much.I am the admin and loading Procmon
in dos is way more than I'm prepared to do. I hope for an easier solution.What puzzles
me is why the error occurs even tho I install from F: having deleted the controller and
the utility and reinstalled both, the utility from F: ??

troop wrote:
In article , says...
http://en.wikipedia.org/wiki/Assert
"...to reason about program correctness"

The software developer feels, that at line 529 in his Winregistry.cpp code,
that something should already be open. The ASSERT check is a check
done for logical correctness. It means the software developer
already did the "open" operation previously, and the item in question
should still be open, and it is not. Thus, the ASSERT, which checks
that the condition is true, has failed.

My guess would be, some key in a registry hive was open, and somehow, it is
now closed. It could be a logic error in the program, or that the item in
the registry never managed to be opened in the first place.

You could try re-installing the utility as "Administrator", and see if that helps.

You can also use one of the Sysinternals programs, and trace the execution of
mimo.exe and see the log of registry keys it is opening or attempting to open.
That in turn, may give a hint as to what part of the registry the program cannot
access to make changes.

Sysinternals Process Monitor.

http://technet.microsoft.com/en-ca/s.../bb896645.aspx


Thank you. I do not want to trace the thing that much.I am the admin and loading Procmon
in dos is way more than I'm prepared to do. I hope for an easier solution.What puzzles
me is why the error occurs even tho I install from F: having deleted the controller and
the utility and reinstalled both, the utility from F: ??

It is easily possible for the registry to be changed in such a way, that
removal and re-installation will not correct the situation. I tried that
with my sound card problem first, before I started using Process Monitor on
it. And that is when I noticed the damage to the registry, that another
sound device driver installation had done.

If the problem did not exist yesterday, but exists today, you could use
System Restore and a restore point before the problem happened, to try to
fix it. But since you last used the utility a long time ago, it is
unlikely that System Restore is going to fix it for you. And System
Restore must be used with care, due to the way it tracks changes on
the system. (It erased some downloads on me - you have to understand
which changes are tracked and which are ignored, to safely use it.
I started researching it, after I noticed some data files disappear.)

Paul

In article , says...
It is easily possible for the registry to be changed in such a way, that
removal and re-installation will not correct the situation. I tried that
with my sound card problem first, before I started using Process Monitor on
it. And that is when I noticed the damage to the registry, that another
sound device driver installation had done.

If the problem did not exist yesterday, but exists today, you could use
System Restore and a restore point before the problem happened, to try to
fix it. But since you last used the utility a long time ago, it is
unlikely that System Restore is going to fix it for you. And System
Restore must be used with care, due to the way it tracks changes on
the system. (It erased some downloads on me - you have to understand
which changes are tracked and which are ignored, to safely use it.
I started researching it, after I noticed some data files disappear.)

Thank you again.