Closed GoogleCodeExporter closed 9 years ago
Well, i'm not sure, but on my notebook the error hint comes first time with new
INTEL MEI v8.x.
Then i tested to delete the OHM config-file, restart the notebook - and the
error hint don't come back...
Doing the same on Desktop - same result: error hint is missing now.
Can You verify this?
Original comment by microsof...@freenet.de
on 20 Sep 2012 at 7:50
Thank you for posting the details. I can see this problem (error in event
viewer) happening on this system as well, but only very rarely. The entry in
the registry is correct, and gets also deleted correctly once the Open Hardware
Monitor exits.
Of course the error entry in the event viewer is not great, but I do not really
know why that happens. Before trying to start the driver (service) the Open
Hardware Monitor checks once more if the file exists and if it has the correct
size. It attempts to start the driver only if both is true. Strange enough, if
the first attempt fails, the second attempt (tried 2s later) might succeed,
even without creating a new driver file (or changing it). So the file exists,
is correct and can be loaded, but at first the system claims, the file isn't
there (at least for loading as driver).
I have created a new version that extracts the driver to the application folder
(instead of the current users temp folder). Maybe that solves the problem
(perhaps the user folder is too virtualized or anything, I do not really have a
clue). You can try with this new version:
http://openhardwaremonitor.org/files/openhardwaremonitor-v0.5.1.3-alpha.zip
Btw. I have only Intel MEI v7.0 installed, and the problem is still visible
rarely.
Original comment by moel.mich
on 20 Sep 2012 at 8:14
In the last houer i have verified that it depends on the installation of IMEI
(must do an downgrade because of an de-/install error). After every install
(IMEI v7 or v8) and restart i get a new error hint, and after delete OHM config
file it is gone... ...still crazy!
But at this time it is solved ;-)
Question: why deleting the config file solves the error??
Original comment by microsof...@freenet.de
on 20 Sep 2012 at 8:48
Can you reproduce the error with the above linked version 0.5.1.3 alpha?
The dependence on IMEI or deleting the config file could be caused by a
different timing when starting the Open Hardware Monitor. If there is no config
file, then the Open Hardware Monitor starts a bit faster (tries to load the
driver earlier). Maybe also installing IMEI delays the start of the Open
Hardware Monitor so it is started in a more critical situation.
Original comment by moel.mich
on 21 Sep 2012 at 5:35
I think I have found the problem, and can reproduce it here (with 0.5.1.2 Alpha
and earlier).
The Open Hardware Monitor used a different name (temp file name given by the
system) for extracting and installing the driver. When the Open Hardware
Monitor exits it uninstalled the driver (deleted the service). On system
shutdown it can happen that the Open Hardware Monitor is notified to late, so
it doesn't get the time required for proper shutdown. This might also be the
reason why config file size matters. With a smaller config file it gets earlier
to the uninstall of the driver.
Now when the system restarts, the Open Hardware Monitor finds that there is
still a WinRing0_1_2_0 service present and thinks that maybe another
application has installed it and is using it. So it tries to use that service,
but of course trying to start it fails, because the temp file with the driver
is long gone. After noticing this problem, the Open Hardware Monitor removes
the service and creates a new one where the file is present so it can be
started.
With version 0.5.1.3 alpha the problem might be "hidden" as it uses always uses
a default file name OpenHardwareMonitor.sys in the application folder. So
reusing the service that didn't get uninstalled from the last run should not
fail here, as the file is provided once more.
In my current understanding the version version 0.5.1.3 alpha should fix the
problem, but I will have to look into this once more to make sure things are
really handled optimally. I should also investigate why the uninstall of the
driver can fail (and if there is a fix for that). There might not be a fix for
that (if time runs out there isn't much one can do) but at least the Open
Hardware Monitor should expect a service that didn't get uninstalled from the
last run.
Original comment by moel.mich
on 21 Sep 2012 at 5:57
I understand.
I try to test v0.5.1.3 alpha in the next three days.
But one suggestion: if the useraccount has no rights to write files in the
system / programm folder, can it fail to write the driver file to the
application folder?
For dynamic write / delete (even for config files) in all circumstances it is a
better choice to write in the user folder (ex. app data - and left the files
there).
I think, You will keep the system clear if OHM ist not in use - but (for ex.)
You can also set the service to "disabled" in the registry if OHM shut down.
Original comment by microsof...@freenet.de
on 21 Sep 2012 at 6:46
Hi. As I said.
Without rights to write in the program folder it fails.
Original comment by microsof...@freenet.de
on 22 Sep 2012 at 11:15
Attachments:
Add Info: I think it is not only the latest V x alpha, it fails in the older
versions too.
Original comment by microsof...@freenet.de
on 22 Sep 2012 at 11:19
The above error message is there by design. It is to inform the user, that the
config file could not be saved.
I don't like the idea of config files in (to the user) unknown places. Right
now, deleting the OHM folder removes automatically also all settings. With
hidden settings (in a place the user does not know), there will always be
situations where there is a problem with a config file, and the user wants to
remove all traces of the program, but he can't. For config files in the app
data folder we would need an installer version of OHM.
But how and where the config file is to be saved is a different issue, so if
you have any suggestion for an overall better solution, please create a new
issue.
Original comment by moel.mich
on 22 Sep 2012 at 8:30
In regards to this issue your above report does not show any problem.
Installing the driver fails because you do not have admin rights (and not
because you can't write to the application folder).
Original comment by moel.mich
on 22 Sep 2012 at 8:33
I understand Your intention.
A workaround is to install OHM in the user folder.
But back to the roots.
Currently I can't reproduce the error in the event list (even V x.2 or V x.3
alpha).
And while I am testing with V x.2 alpha, I recognised this:
If OHM has create the regkey "WinRing" on start, OHM delete it on every
MANUALLY shutdown, but an existing (older) entry is not deleted (I am looking
with sysinternals "autoruns").
Might be this is the error (you have said this in Your older post: "...can
happen... ...[if no] proper shutdown.").
Now it seems, that the error is gone.
Original comment by microsof...@freenet.de
on 23 Sep 2012 at 9:34
This issue was closed by revision r420.
Original comment by moel.mich
on 23 Sep 2012 at 6:37
New version for revision r420:
http://openhardwaremonitor.org/files/openhardwaremonitor-v0.5.1.4-alpha.zip
Original comment by moel.mich
on 23 Sep 2012 at 6:39
If you run autoruns the winring0_1_2_0 shows with latest .4-alpha but instead
of path being in a temp path it shows> file not found "path you
unpacked/openhardwaremonitor.sys
Original comment by EdKiefe...@gmail.com
on 5 Oct 2012 at 3:57
PS: I don't see any unpacked drivers from beta 0.5.1 as compared to
0.5.1.4-alpha there only 2 dll (Aga controls.dll and OpenHardwareMonitorlib.dll
) , seems it looking for a OpenHardwareMonitor.sys file .
Original comment by EdKiefe...@gmail.com
on 5 Oct 2012 at 4:03
OpenHardwareMonitor.sys is extracted only for starting the driver. After that
it is deleted. This is correct behavior.
Where do you see an error message with 0.5.1.4? What is the error message
exactly?
What are steps to reproduce the error?
Did this error not occur with 0.5.1 beta?
Original comment by moel.mich
on 5 Oct 2012 at 4:36
hi, I am on win7 and I did see event viewer >system - Log Name: System
Source: Service Control Manager
Date: 10/5/2012 7:50:46 AM
Event ID: 7000
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: Ed-PC
Description:
The WinRing0_1_2_0 service failed to start due to the following error:
The system cannot find the file specified.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Service Control Manager" Guid="{555908d1-a6d7-4695-8e1e-26931d2012f4}" EventSourceName="Service Control Manager" />
<EventID Qualifiers="49152">7000</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8080000000000000</Keywords>
<TimeCreated SystemTime="2012-10-05T11:50:46.513363200Z" />
<EventRecordID>14476</EventRecordID>
<Correlation />
<Execution ProcessID="704" ThreadID="2720" />
<Channel>System</Channel>
<Computer>Ed-PC</Computer>
<Security />
</System>
<EventData>
<Data Name="param1">WinRing0_1_2_0</Data>
<Data Name="param2">%%2</Data>
</EventData>
</Event>
I have not checked or gotten new event with alpha4 (the above was with 0.5.1
beta .
Also I have no issue running OHM , just saw event error and investigated . when
checking autoruns>driver the line shows as I mentioned originally .
Original comment by EdKiefe...@gmail.com
on 5 Oct 2012 at 5:26
Also the winring0_1_2_0 does get removed from the autoruns>driver list when
exiting OHM . the errors in event are random it seems so I have to wait few
days at least to se if they happen with alpha4 build . I only have 4 errors in
2 months time .
Original comment by EdKiefe...@gmail.com
on 5 Oct 2012 at 5:30
Original issue reported on code.google.com by
microsof...@freenet.de
on 20 Sep 2012 at 6:21Attachments: