I/O access suddenly stopped working

[Godzilla]

Hello,

I have an application which require I/O access, to start and refresh
the watchdog chip. I have been using the inpout32.dll (www.lvr.com)
driver to get to access the I/O. Everything were fine under EWF, and
also a non-administrator account. But that is not the case under FBWF;
I simply cannot get the watchdog to trigger a computer restart under a
non-administrator account. The interesting thing is when I load the
same application under administrator account, everything worked as
expected.

I am unsure why the application misbehave under the non-administrator
account on FBWF. Can anyone tell me whether there is any security
policy being changed under FBWF and/or Feature Pack 2007?

Any help will be appreciative. Thank you.

 

[Stefan Pflaume \(XPe\)]

Hello,
you should uset WinIo from http://www.internals.com/.
Try it, it should work without a admin account.
Kind regards
Stefan

 

[KM]

Here mentioned a few more alternatives: http://km-dev.blogspot.com/2007/03/xpe-tip5-direct-io-operations-from.html

Although I am wondering why EWF and FBWF were mentioned in the original post.

 

[Godzilla]

Thank Stefan and KM.

However, I am still unable to get the FBWF image to run the watchdog
application on a non-administrative account.

The reason why I mention EWF and FBWF is that I am seeing two
different results. The setup is as follow:
* Watchdog application (using inpout32.dll, reside on the same folder
as the app.),
* Running watchdog application under non-admin account:

Result
- EWF image: trigger the watchdog chip whenever it is instructed to...
- FBWF image: DOES NOT trigger the watchdog chip whenever it is
instructed to...

Both images are essentially the same; the only difference is EWF and
FBWF... why is that the case?! I am still seeing this anomally as we
speak. We are at a lost why this is the case under FBWF.

Anyone has experience the direct I/O access problem under FBWF image?

 

[S.P. \(XPe\)]

I only have a guess, and it could be completely wrong!

Maybe the inpout32.dll is using some kind of "File In/out" and wrap that to
write to the hardware I/O port.

In that case, the FBWF will redirect the write action to the overlay.

Have you tried some of the other solutions KM has recommended?

You should give it a try, as I can see no explainable reason the EWF is
working and the FBWF doesn't.

 

[Godzilla]

Hello SP,

Thank you for your promptly reply. I am unsure how the inpout32.dll
works... But I do know that it embeds all the kernal mode codes in
itself. Hence it does not require any *.sys file whatsoever.

I had a go at WinIO library, and found it a tad difficult to use. I
was not able to mod my code to work with WinIO, even under
administrator account. I think I need to call some init function
before using the driver... I will double check that code tomorrow and
hopefully get it to work under administrator account first.

Cheers

 

[S.P. \(XPe\)]

Hello Godzille,
what programming language are you using?

Maybe I can post a short sample of using the WinIo.

 

[KM]

Just out of curiosity.. What FBWF settings do you use in that "FBWF image"?
Do they match EWF settings? (in other words, do you protect the entire volume or some files/folders only?)

If you launch your app with the FileMon (ProccessMonitor) tool running you may be able to see if the inpout32 library is trying to
write/read anything on the disk.

 

[Godzilla]

Thank you, SP and KM for your help. It's been worthwhile...

I was able to get it to work on WinIO afterall. Although I still do
not know the exact reason why I couldn't get it to work on
inpout32.dll... it maybe one of those issue I would never know...

KM, I was thinking about the FBWF potentially filters out some file
writes, so I turned off the filter, rebooted the computer. But the
watchdog code still does not trigger after the reboot.

SP, the watchdog code is pretty much done in C++. Having said that, I
was very tempted to use Python for this little script...

Again, thank you for all your help.

Cheers

 

[KM]

Thank you for reporting the results.

Although it is still a bit weird that FBWF caused the issue. I'd report the bug (issue) to the product team via the feedback alias.

 

[Godzilla]

Thanks KM... Also, can you please ensure that the embedded team knows
about the "fbreseal.exe -keepall" will kill IIS after the cloning?
That costed me one Sunday of testing before I found that the "-
keepall" option was to blame. The error message was every time you
tried to start the IIS Admin, it returns with the error code
"2146893818".

Hopefully no one else will have to go through what I did.

Good luck.

 

[KM]

Well, I bet the Product Team is well aware of the IIS issues after cloning since similar issues have been reported here many times
and most of them were (are) documented in release notes.

I guess, it is hard to fix the bugs without changing the IIS binaries (in other words, the issue has to be fixed with the sources).