Error hint in Window XP Event list (System) service "WinRing0_1_2_0" fails to start

[GoogleCodeExporter]

What version of the product are you using? On what operating system?
v0.5.1.2 Alpha on WinXP Pro 32bit SP3

Please provide any additional information below.
Entry for service "WinRing0_1_2_0" in registry points to a file which not 
exists.

Please attach a Report created with "File / Save Report...".

Original issue reported on code.google.com by microsof...@freenet.de on 20 Sep 2012 at 6:21

Attachments:

• EventList.JPG
• Registry.JPG
• WinRing0_1_2_0.reg.txt
• OpenHardwareMonitor.Report.txt

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

• Changed state: NeedsInfo

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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:

• Fail_User_NoAdmin.JPG
• Error_User_NoAdmin.JPG
• OpenHardwareMonitor.Report_User_NoAdmin.txt

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

This issue was closed by revision r420.

Original comment by moel.mich on 23 Sep 2012 at 6:37

• Changed state: Fixed

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

Hello all, I think, it is a misunderstanding.

"EdKiefe" said: "If you run autoruns the winring0_1_2_0 shows [...] "path you 
unpacked/openhardwaremonitor.sys"

This is correct, no error and by design. The entry is deleted every shutdown of 
OHM. You can test it: shut down OHM and rerun "sysinternals autoruns". The 
entry is gone...

Original comment by microsof...@freenet.de on 5 Oct 2012 at 5:35

[GoogleCodeExporter]

That the driver is listed in Autoruns while the Open Hardware Monitor is 
running is correct. That the file does not exist while the driver is running is 
correct as well. 

The error event showing with 0.5.1 Beta is a known bug and fixed with 
0.5.1.4-alpha.

So I do not see any new problem and leave this Issue as "Fixed".

Original comment by moel.mich on 5 Oct 2012 at 5:40

[GoogleCodeExporter]

ok, great .

Thats my bad, I "assumed" if it shown in sutoruns it may show in event viewer .

great work then, 
thanks 

Oh, is there a alpha build directory I could check for new alphas over time (if 
you release them of course ) .

Original comment by EdKiefe...@gmail.com on 5 Oct 2012 at 5:43

[GoogleCodeExporter]

atm there isn't an alpha build directory. If I will ever add one, than it will 
be linked from the website.

Original comment by moel.mich on 5 Oct 2012 at 5:52

[GoogleCodeExporter]

ok, thanks

Original comment by EdKiefe...@gmail.com on 5 Oct 2012 at 5:59