[brettsh]

Justin, that event you are talking about, I assume is ESENT event 642? If so, that was literally - MY fault. Not the ESE teams fault, but _MY_ fault. Feel free to reply here with your flame. ;-) I can handle it. Really. :)

In the server cloud business all the events streams (and we have several) are rolled up into optics web reports and analyzed and sifted for potential emergent issues and health metrics ... in this case, an event useful to our cloud server business leaked into the events of our Windows client business. This is (in my biased opinion;) less about being "server grade", and more about not being "properly embeddable" ... as generally embedded components should be quiet.

This is part of the challenge of making a DB engine that services two very divergent scenarios. This is the smallest of those challenges. How much memory we can allocate being the largest regular conflict ... Office 365 would not even notice if ESE allocated an extra 1 MB per process, but that would boost our Working Set numbers by 40% (from the last numbers I remember seeing) for each Windows Client Service using us.

Anyways, I have fixed the code to not log that event on Windows Client. It should clear up once that patch gets out.

Cheers, Brett Shirley [MSFT]

P.S. - Oh and I am sorry if it caused you any stress. I know it sounds concerning, but it is truly innocuous. You can ignore it, and hopefully soon you won't see it.

[justin66]

There are some of those! Along with 330, 105, 301, 326, 641, 302, 102, 103, 300, and I just assume a few others, all coming from ESENT.

I guess that's a question: what would it look like on a Windows 10 system if it had a truly broken ESENT installation? As far as I know ESENT has never directly been a problem. Its log output is just part of the noise that now makes using the Event Viewer a complete waste of time unless one knows precisely when a problem was logged.

> Feel free to reply here with your flame. ;-) I can handle it. Really. :)

Believe me, if I thought the state of the Event Viewer and its logs were the fault of any one person, I'd be able to muster some sort of impassioned, vituperative response. I'm not angry, son, I'm just so disappointed in you. Ahem.

[brettsh]

LOL! "Disappointed", Nice, Justin. :)

Those other ones are Information events however, not Warning events. ESE (as part of being "embeddable") has a couple of logging level controls (JET_paramEventLoggingLevel, and JET_paramNoInformationEvent). Each component is responsible for setting it's event logging level, the ESE default is ... let me call it, "fully diagnosable mode" (for us, not you ;).

Anyways, all events start like this: "svchost (48984,R,98) TILEREPOSITORYS-1-5-18 .." ... the service exe name at beginning, and the "instance" name there at the end. If you get me a few of the noisier components, I will try to find the Windows component owners and suggest to them that they set the logging level higher.

Thank You, Brett Shirley [MSFT]