Prev: pins for for power supply
Next: Asus A33 DAV
From: mikea on 12 Apr 2010 11:08
DaMonkeyBoy <Kleptic(a)large.com> wrote in <4r35s5d4us70b4uojimrccv5j6kuegem4h(a)4ax.com>:
> So I boot up today and I get this error from fourengine.exe:
>
> Assertion failed: !IsOpen() && name ! = NULL, file
> G:\Marklib\incude\dali\System\WinPipe.cpp, line 268
>
> Any ideas on what this means? G drive is one of my dvd drives

That is a message that I'd expect from a failed compile.

It appears to be saying that

G:\Marklib\incude\dali\System\WinPipe.cpp

wasn't open when it was expected to be, and that its name was not NULL
when you were doing something that wanted to use (read from, I hope)
that file. Did you have in the drive the CD or DVD that was expected to
be there? Did you possibly misspell "include" as "incude", leaving out
an "l"?

Are you running on Windows 7? Is fourengine.exe compatible with Windows 7?

--
/ "I think I've figured out why that FreeBSD box is oozing green ichor \
[ - I think it may be due to having the NT PDC only a foot or two away." ]
\ -- Lionel (shamelessly stolen from AdB's sig in asr) /
From: Paul on 12 Apr 2010 21:29
mikea wrote:
> DaMonkeyBoy <Kleptic(a)large.com> wrote in <4r35s5d4us70b4uojimrccv5j6kuegem4h(a)4ax.com>:
>> So I boot up today and I get this error from fourengine.exe:
>>
>> Assertion failed: !IsOpen() && name ! = NULL, file
>> G:\Marklib\incude\dali\System\WinPipe.cpp, line 268
>>
>> Any ideas on what this means? G drive is one of my dvd drives
>
> That is a message that I'd expect from a failed compile.
>
> It appears to be saying that
>
> G:\Marklib\incude\dali\System\WinPipe.cpp
>
> wasn't open when it was expected to be, and that its name was not NULL
> when you were doing something that wanted to use (read from, I hope)
> that file. Did you have in the drive the CD or DVD that was expected to
> be there? Did you possibly misspell "include" as "incude", leaving out
> an "l"?
>
> Are you running on Windows 7? Is fourengine.exe compatible with Windows 7?
>

The file reference

G:\Marklib\incude\dali\System\WinPipe.cpp line 268

refers to the line of source code (written by Asus) that is
raising the assert error. So that G: disk, is a disk at Asus.
It is a disk on the computer of the code developer.

I'm not a software developer, but from what I understand, an ASSERT
is used to check for logical correctness in a program.

Say you write a program, and it opens a file for writing. The program
might use a dialog box or have some other means of user input. That
would *not* be a good place to be using ASSERT code. If you're dealing
with user input, you would use regular error handling, such as

IF (condition_not_met) THEN print error message and stop.

An ASSERT would be used in a situation, where it is virtually impossible
for something to be wrong. Say, for example, in the first line of
code, you assign the variable N = 1. Then, in the next line of code,
you do an ASSERT check, that N is still equal to one. Well, from a
programming perspective, you'd likely say "why use that assert then ?".
And in some cases, you'd be right. You can't ASSERT check everything, and
it would be silly to do so. If a variable is assigned a value, and you don't
touch that variable, it would be a waste of lines of code, to be continually
doing ASSERT checks that it is still equal to 1.

In a way, an ASSERT is almost like a comment being placed in the code.
In my last example, it is a way for the developer to say "Hmmm. I think
N is still equal to 1 at this point. If I'm wrong, shoot me." The chances
of him being wrong, would normally be very slight. Perhaps a memory
error could cause my example of an ASSERT to fail, but otherwise, it
should never happen. And that is the nature of ASSERTs - they should
really never be raised, and especially in code shipped to a customer.

I would say, in this case, that Asus are ASSERT abusers. This is not the
first time I've heard of one of the Asus utilities throwing an ASSERT.
I think someone there, skipped one of their programming classes :-)
Programmers are by nature lazy, and hate adding proper error checking code.
If something can go wrong (like things involving interaction with the
user), it should be handled by regular error checking code. ASSERTs
are normally used, like dessert topping - if a developer uses a particularly
elegant software structure, an ASSERT might be jammed into the code,
to say in effect "See how clever I am ?". I've seen cases where the
ASSERT is used like a "wink wink nudge nudge" in the code, rather
than being there for practical purposes. So there is presumably a
discipline to using the ASSERT, and my observations about it above,
are based on reviewing the code of others.

*******

With respect to the original question, the only thing a user can do,
is uninstall the current version of Asus utility, then download any
update from support.asus.com or support.asus.com.tw and install that
instead.

If instead, you want to debug the execution of "fourengine.exe", you could
use Process Monitor from Sysinternals. But I don't know how well that
would work during system startup. I've used Process Monitor to figure
out stuff, when the system is running. But when the system starts up,
I don't know what program you could use to monitor what is happening
there. (I don't know if Process Monitor could be used as a Startup item.)

Process Monitor can tell you about Registry operations, file reads,
writes, and so on. The Filter menu in the program is the
key to getting useful results, and has a large menu of events to
look for. For example, I was using it the other day, looking for
"Operation" "Is" "WriteFile" to trace all writes to disk. It's really
a handy little program.

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

Some antivirus programs hate when the Sysinternals programs run,
so if you're using Kaspersky AV, disable Kaspersky before starting some
of the programs like that one. Kaspersky will lock up the computer, when
a Sysinternals program starts tickling sensitive system structures.

Paul
 | 
Pages: 1
Prev: pins for for power supply
Next: Asus A33 DAV