TraceLog while system bootup

How i can get the logs which shows the inbox driver why it get fails ( Why it shows the yellow mark in the device manager)

could you pls help on how to use the TraceView logs to get the logs in windows where it saves and is there any help on this. I will install the Winddk 10 on windows 10 machine.

I need to get the logs for inbox driver which is shown yellow mark.

Where the logs will create and how i can analyze it.

xxxxx@gmail.com wrote:

How i can get the logs which shows the inbox driver why it get fails ( Why it shows the yellow mark in the device manager)

could you pls help on how to use the TraceView logs to get the logs in windows where it saves and is there any help on this. I will install the Winddk 10 on windows 10 machine.

I need to get the logs for inbox driver which is shown yellow mark.

Where the logs will create and how i can analyze it.

There might not be any logs. First, go to Device Manager to find what
the failure code was. That leads to the next steps. It’s possible you
might find information in the setup logs, c:\windows\inf\setupapi.dev.log.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Is there any way to get the details about why it fails. We are updating the
firmware where that inbox driver is using it.
Could you please give me the suggestion tat how I can get the trace log why
it failed ?
On 23 Jan 2017 10:31 p.m., “Tim Roberts” wrote:

> xxxxx@gmail.com wrote:
> > How i can get the logs which shows the inbox driver why it get fails (
> Why it shows the yellow mark in the device manager)
> >
> > could you pls help on how to use the TraceView logs to get the logs in
> windows where it saves and is there any help on this. I will install the
> Winddk 10 on windows 10 machine.
> >
> > I need to get the logs for inbox driver which is shown yellow mark.
> >
> > Where the logs will create and how i can analyze it.
>
> There might not be any logs. First, go to Device Manager to find what
> the failure code was. That leads to the next steps. It’s possible you
> might find information in the setup logs, c:\windows\inf\setupapi.dev.log.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:>

Prabhakar V wrote:

Is there any way to get the details about why it fails. We are
updating the firmware where that inbox driver is using it.
Could you please give me the suggestion tat how I can get the trace
log why it failed ?

It’s like you didn’t even read my first message. I GAVE you the first
two steps, and it doesn’t look like you didn’t take either one.

If you are screwing with a device so it is inaccessible while a driver
expects to be using it, then you should not be surprised that the driver
explodes. Drivers do not log every single action. A PCI driver expects
to be able to access PCI registers.

If you expect better advice, you’re going to need to tell us what kind
of device, what you are doing to it, and what Device Manager error code
you got.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

On 23 Jan 2017 10:31 p.m., “Tim Roberts” > mailto:xxxxx> wrote:
>
> xxxxx@gmail.com mailto:xxxxx wrote:
> > How i can get the logs which shows the inbox driver why it get
> fails ( Why it shows the yellow mark in the device manager)
> >
> > could you pls help on how to use the TraceView logs to get the
> logs in windows where it saves and is there any help on this. I
> will install the Winddk 10 on windows 10 machine.
> >
> > I need to get the logs for inbox driver which is shown yellow mark.
> >
> > Where the logs will create and how i can analyze it.
>
> There might not be any logs. First, go to Device Manager to find what
> the failure code was. That leads to the next steps. It’s
> possible you
> might find information in the setup logs,
> c:\windows\inf\setupapi.dev.log.
></mailto:xxxxx></mailto:xxxxx>

It’s a USB type c connector device which it manages the power policy where
it gives the error code 10 of power device failure and shown yellow bank in
the device manager , firmware they ve updated properly and we need to
coordinate the inbox driver to be support with this device.

This one I need to pass the hlk test in windows 10 machine
On 23 Jan 2017 11:07 p.m., “Tim Roberts” wrote:

> Prabhakar V wrote:
> >
> > Is there any way to get the details about why it fails. We are
> > updating the firmware where that inbox driver is using it.
> > Could you please give me the suggestion tat how I can get the trace
> > log why it failed ?
> >
>
> It’s like you didn’t even read my first message. I GAVE you the first
> two steps, and it doesn’t look like you didn’t take either one.
>
> If you are screwing with a device so it is inaccessible while a driver
> expects to be using it, then you should not be surprised that the driver
> explodes. Drivers do not log every single action. A PCI driver expects
> to be able to access PCI registers.
>
> If you expect better advice, you’re going to need to tell us what kind
> of device, what you are doing to it, and what Device Manager error code
> you got.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
>
> > On 23 Jan 2017 10:31 p.m., “Tim Roberts” > > mailto:xxxxx> wrote:
> >
> > xxxxx@gmail.com mailto:xxxxx wrote:
> > > How i can get the logs which shows the inbox driver why it get
> > fails ( Why it shows the yellow mark in the device manager)
> > >
> > > could you pls help on how to use the TraceView logs to get the
> > logs in windows where it saves and is there any help on this. I
> > will install the Winddk 10 on windows 10 machine.
> > >
> > > I need to get the logs for inbox driver which is shown yellow mark.
> > >
> > > Where the logs will create and how i can analyze it.
> >
> > There might not be any logs. First, go to Device Manager to find
> what
> > the failure code was. That leads to the next steps. It’s
> > possible you
> > might find information in the setup logs,
> > c:\windows\inf\setupapi.dev.log.
> >
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:></mailto:xxxxx></mailto:xxxxx>

Prabhakar V wrote:

It’s a USB type c connector device which it manages the power policy
where it gives the error code 10 of power device failure and shown
yellow bank in the device manager , firmware they ve updated properly
and we need to coordinate the inbox driver to be support with this device.

I’m sorry, but your sentence does not make sense.

Here’s what I understand. You have a USB 3 device, which is supported
by an inbox driver. The inbox driver come up with a code 10, which
means it failed during the “start device” process.

Now, are you loading firmware during every boot? Is that happening
automatically in the hardware, or is this something you trigger in
another driver? Your device should not enumerate as a standard device
until it is totally ready to handle standard device requests. Is that
the issue here? The inbox driver gets loaded before you are ready? If
so, that’s a hardware problem. You have to fix your device so it does
not enumerate until it is ready, or may force it to re-enumerate after
it is ready.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Thank you Tim.

>Here’s what I understand. You have a USB 3 device, which is supported
>by an inbox driver. The inbox driver come up with a code 10, which
>means it failed during the “start device” process.

Yes correct tim. How we can take the TraceLog where it fails it return with
Error Code 10 of Power failure.

Link :
https://msdn.microsoft.com/en-us/windows/hardware/drivers/devtest/tracelog

>Now, are you loading firmware during every boot? Is that happening
>automatically in the hardware, or is this something you trigger in
>another driver? Your device should not enumerate as a standard device
>until it is totally ready to handle standard device requests. Is that
>the issue here? The inbox driver gets loaded before you are ready? If
>so, that’s a hardware problem. You have to fix your device so it does
>not enumerate until it is ready, or may force it to re-enumerate after
>it is ready.

Firmware has been flashed over that hardware and reboot again , it
enumerated as a standard device and PDO were shown in the device manager
but fails in Power device failure with code 10. I think you have shared the
information regarding the setupap log may it will be useful why it get
failed in tat case.

Regards,

Prabhakar Vinayagam

Prabhakar V wrote:

>>Here’s what I understand. You have a USB 3 device, which is supported
>>by an inbox driver. The inbox driver come up with a code 10, which
>>means it failed during the “start device” process.

Yes correct tim. How we can take the TraceLog where it fails it return
with Error Code 10 of Power failure.

Link :
https://msdn.microsoft.com/en-us/windows/hardware/drivers/devtest/tracelog

YOU CAN’T USE TRACELOG FOR THIS. You simply cannot assume that every
driver is logging every action. It’s just not true. If you had told us
which standard driver it is (which you still haven’t said), then MAYBE
one of the engineers would know of some trace messages, but that is a
longshot.

Firmware has been flashed over that hardware and reboot again , it
enumerated as a standard device and PDO were shown in the device
manager but fails in Power device failure with code 10. I think you
have shared the information regarding the setupap log may it will be
useful why it get failed in tat case.

I don’t know what you mean by “fails in Power device failure”. What
does power have to do with it?

Look, the problem is your hardware has a bug. You aren’t recovering
quickly enough after redoing the firmware. You need to wait to
re-enumerate until you are ready to handle requests. It’s just not that
mysterious.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Prabhakar V wrote:

when they have updated the firmware that time when it boots up ,
windows scrolling was still going on how we can find that why it is
failing to go up for windows 10 OS.

Is der any way to get the logs or how i can find that which cause of
that inbox driver Ucmucsi.sys causes the driver not to bootup the
windows 10 machine.

OK, that’s the first time you’ve said which driver is failing. What are
you creating, exactly? Are you creating a USB host controller? If not,
I’m not sure why ucmucsi.sys should be involved.

Could you please help on what are the debug way when they have updated
the firmware for a particular device where it has the inbox driver
shows the yellow mark , what are the way i can fix the error ?

https://msdn.microsoft.com/en-us/library/windows/hardware/mt710944(v=vs.85).aspx#ucsi_commands_required_by_windows
https:
>
> Where it has the UCSI exection command to test the inbox driver but it
> failes with yellow mark.

There are no general rules for this. If the UCSI driver is failing,
then your host controller is not following the UCSI rules in some way.
You may have to have some traces in your hardware to figure out which
commands you are getting, to make sure you’re responding in a timely manner.

> if that windows doesnt bootup tat means still scrolling in that case
> how i can create a log that which causes the inbox driver of USB type
> C to fails to load the windows 10 machine.

There are no documented trace providers for UcmUcsi.sys. There might be
some, but we don’t know how to get them.

> If suppose in one BIOS level i can bootup the machine in some BIOS it
> doesnt bootup to OS level , how i can save the last known good
> configuration , in some cases the harddisk may corrupted , how i can
> eliminate those error and bootup with the last known good configuration ?

You can’t. If your crash causes the disk to get corrupted, then you get
to start over. Are you running with the kernel debugger so you can look
around when it crashes?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.</https:>

Hi tim,

>OK, that’s the first time you’ve said which driver is failing. What are
>you creating, exactly? Are you creating a USB host controller? If not,
>i’m not sure why ucmucsi.sys should be involved.

We have updated the firmware for that chip which inbox driver (ucmucsi.sys
) is used.
Now the inbox driver is failed that trace in which case it is failed that
one i have to debug so that firmware team will change the code.

>There are no general rules for this. If the UCSI driver is failing,
>then your host controller is not following the UCSI rules in some way.
>You may have to have some traces in your hardware to figure out which
>commands you are getting, to make sure you’re responding in a timely
manner.

Driver is shown in yellow mark so i cant execute the UCSICommand.exe
command line utility to check the inbox driver satisfied all the commands.

https://msdn.microsoft.com/en-us/library/windows/hardware/mt710944(v=vs.85).aspx#ucsi_commands_required_by_windows

Traces to be get through in this TraceView command line utility in which we
have to specify the GUID of that device or PDB

http://www.osronline.com/article.cfm?article=213

Could you please help on which way i can get the trace in which cases it
failed.

For this device oly i need to run the HLK test cases to be passi in which
wat are the hardware requirement for USB Type C connector device in which
it passes the test case and to get certification, i have mailed to support
team but they have not answered.

On Wed, Jan 25, 2017 at 1:18 AM, Tim Roberts wrote:

> Prabhakar V wrote:
> >
> > when they have updated the firmware that time when it boots up ,
> > windows scrolling was still going on how we can find that why it is
> > failing to go up for windows 10 OS.
> >
> > Is der any way to get the logs or how i can find that which cause of
> > that inbox driver Ucmucsi.sys causes the driver not to bootup the
> > windows 10 machine.
>
> OK, that’s the first time you’ve said which driver is failing. What are
> you creating, exactly? Are you creating a USB host controller? If not,
> I’m not sure why ucmucsi.sys should be involved.
>
>
> > Could you please help on what are the debug way when they have updated
> > the firmware for a particular device where it has the inbox driver
> > shows the yellow mark , what are the way i can fix the error ?
> >
> > https://msdn.microsoft.com/en-us/library/windows/hardware/
> mt710944(v=vs.85).aspx#ucsi_commands_required_by_windows
> > https:> hardware/mt710944%28v=vs.85%29.aspx#ucsi_commands_required_by_windows>
> >
> > Where it has the UCSI exection command to test the inbox driver but it
> > failes with yellow mark.
>
> There are no general rules for this. If the UCSI driver is failing,
> then your host controller is not following the UCSI rules in some way.
> You may have to have some traces in your hardware to figure out which
> commands you are getting, to make sure you’re responding in a timely
> manner.
>
>
> > if that windows doesnt bootup tat means still scrolling in that case
> > how i can create a log that which causes the inbox driver of USB type
> > C to fails to load the windows 10 machine.
>
> There are no documented trace providers for UcmUcsi.sys. There might be
> some, but we don’t know how to get them.
>
>
> > If suppose in one BIOS level i can bootup the machine in some BIOS it
> > doesnt bootup to OS level , how i can save the last known good
> > configuration , in some cases the harddisk may corrupted , how i can
> > eliminate those error and bootup with the last known good configuration ?
>
> You can’t. If your crash causes the disk to get corrupted, then you get
> to start over. Are you running with the kernel debugger so you can look
> around when it crashes?
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:></https:>

Prabhakar V wrote:

>>OK, that’s the first time you’ve said which driver is failing. What are
>>you creating, exactly? Are you creating a USB host controller? If not,
>>i’m not sure why ucmucsi.sys should be involved.

We have updated the firmware for that chip which inbox driver
(ucmucsi.sys ) is used.

OK, so your hardware/firmware is in the host? You’re not a device at all?

Now the inbox driver is failed that trace in which case it is failed
that one i have to debug so that firmware team will change the code.

Does it only fail once, immediately after the reload, and then work when
you reboot? Put another way, is the failure because of the firmware
load process, or does your new firmware cause the problem?

Driver is shown in yellow mark so i cant execute the UCSICommand.exe
command line utility to check the inbox driver satisfied all the commands.

How much debug stuff do you have in your firmware? If you can capture a
trace log in your firmware, you could grab the list from a working run,
then see how far it actually gets with your new firmware. That should
tell you which request is failing.

Could you please help on which way i can get the trace in which cases
it failed.

Unfortunately, someone has to tell you this. There are thousands and
thousands of trace providers in the system, and there is no central
list. You may need to file a Windows product support incident, so you
can get hooked up with the UCM product team in Redmond. They are the
only ones who can guide you.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.