다음을 통해 공유

How to capture a Dbgview trace from Windows Core

  • 아티클

Occasionally I find it necessary to capture a Dbgview trace from a Core installation of Windows Server 2008. This commonly occurs as more and more people use a Core server as their VMM Host in either a P2V or V2V scenario. When troubleshooting such an issue, CSS may need to capture Dbgview traces from all three servers involved (VMM server, host and source). What follows are the instructions to capture a Dbgview trace from a Windows Server Core installation. For general instructions on how to setup/configure a Dbgview trace, please refer to Cheng’s blog.

Steps to capture Dbgview trace on a Core server

a. Copy the folder with all the Dbgview files to a local folder off the root of C drive like C:\Dbgview

b. From an administrator’s command prompt change to the C:\Dbgview directory

c. Type odson.reg (if this fails, add the registry entry manually)

d. Type odsflags.cmd 255 (or 0xffffff alternatively)

e. Restart services:

net stop vmmservice

net stop vmmagent

iisreset

net start vmmservice

net start vmmagent

f. Type dbgview.exe

g. Dbgview should start capturing data

However, on some Windows CORE installations the following error message then appears.

clip_image001

The obvious answer is to add the following privileges to the logged on user:

  1. Load and unload device drivers
  2. Debug programs

But how do you add those rights?  Since we don’t have any UI in Core there are two ways that I know of that you can configure this.

  1. Create a new template with these rights and apply to the Core server.
    1. On a non-Core server, open a new mmc
    2. Load the Security Templates snap-in 
    3. Right click on Security Templates, and select New
    4. Name the new template Debug
    5. Expand Debug, then Local Policies followed by User Rights Assignments
    6. Modify the necessary rights
    7. Save the new template
    8. Copy the template to the Core server
    9. Use the Secedit /configure to apply template

I’ve included an example of a properly configured secedit command.

secedit /configure /db hisecws.sdb /cfg hisecws.inf /overwrite /log hisecws.log

In this example, the db hisecws.sdb is used.  However you can use really any database because we’re only using it for a very brief amount of time and not making any changes to it.  We merely need the place holder.  The hisecws.inf would be the name of the template created above (Debug.inf).

The following link talks more about using the SECEDIT command.

https://technet.microsoft.com/en-us/library/cc737638.aspx

2. Another option is to either modify the default domain policy or create a new group policy object that includes these rights and apply to the OU where the Core server resides.  Then either wait for policy to refresh or run gpupdate /force to immediately apply the new policy.  This may be the easier way to go but not sure if this is possible in your environment.

This is part of the fun with running Server Core J

3. Another alternative would be to take the Host out of the equation altogether and simply try the P2V conversion to the VMM server directly as a test.

Comments

  • Anonymous
    January 01, 2003
    This could come in handy when troubleshooting Windows Core VMs… Feed: System Center Virtual Machine Manager

  • Anonymous
    January 01, 2003
    This could come in handy when troubleshooting Windows Core VMs… Feed: System Center Virtual Machine Manager

  • Anonymous
    January 01, 2003
    Collecting traces while reproducing an issue is one of the best methods we have of determining the source

  • Anonymous
    January 01, 2003
    Collecting traces while reproducing an issue is one of the best methods we have of determining the source

  • Anonymous
    January 01, 2003
    Summary In order to diagnose a failure scenario in System Center Virtual Machine Manager, it is normally