This week’s BEACON Researchers at Work post is by MSU graduate student Michelle Vogel.
Since this is the tale of how I ended up as an intern and future employee of Microsoft, I guess I should tell you a bit about myself. My name is Michelle Vogel, and I am currently a Masters Student at Michigan State University in Computer Science Engineering (CSE). If you couldn’t tell from the title, I did not start out in computer science engineering and I never thought in a million years I would end up working for one of the largest tech companies in the world.
I discovered CSE in Dr. Punch’s Introduction to Computer Science course, my last semester of my senior year of my undergraduate degree, making me a late bloomer compared to most in the field. The course taught basic programing in Python, and I decided I had to learn more. I was fascinated by the challenges posed to me and the ability to use programming to solve biological problems. I spent the next year taking classes and learning all I could about CSE. I also spent a considerable amount of time performing research in conjunction with Drs. Heather Goldsby, Aaron Wagner and Charles Ofria. The next year I started the master’s program in CSE and began a project with Dr. Ofria. In the process of working on my research (an algorithm for tree of life reconstruction) I realized I was more interested in the computer aspect than I was in the biological question I was attempting to solve with my program. Dr. Ofria encouraged me to try and obtain a summer internship in order to see what industry was like as I was uncertain if I wanted to continue on to a PhD program at another university.
Through hard work, perseverance and some luck I was offered an internship position at Microsoft. I knew prior to driving to Seattle that I would be working in Windows as an SDET – Software Development Engineer in Test. SDET’s are responsible for testing all of the production code to try and find and remove as many bugs as possible before the software ships. SDET’s code is run in “lights out” automation labs, which run fully automated tests that require no interaction with a human once the test has been written.
Upon arriving in Redmond I started working with the Device Foundation Team. This team is part of the Hardware Developer Experience in the Windows division of Microsoft. My team is responsible for testing the OS side of drivers. Everyone has dealt with drivers at one point in time or another, usually for installing a new mouse or the dreaded printer driver. What many people are unaware of is that drivers in their most basic form are the interface between the OS and hardware. This means that there are drivers for your hard drive, RAM, processor and virtually every hardware component in your computer. When these critical drivers are not working, your computer is unable to turn on.
My team gave me a unique experience. Instead of assigning me a project on my first day, they provided me a list of possibilities to pick from. I spent the next week learning how to schedule meetings with my coworkers to learn about the projects and setting up my system. I learned more TLAs (three letter acronyms) in that first week than I could count and it would only get worse as I selected what I would work on for the summer and dived into it. After giving the options some serious thought, I decided to work on a set of tools that enable testing of driver specific scenarios in an automated way.
One of the problems I addressed with my project is that drivers are software programs that reside in the same memory space as the software program responsible for running the computer (the kernel). When installation of a driver package goes wrong, the memory space that the operating system occupies may be overwritten or changed by the driver. If this happens, the computer may not turn on, or if the driver malfunctions once it is installed and tries to access the kernel memory, the user may experience a bug check (commonly referred to as the “blue screen of death”). If there isn’t enough memory, or the driver tries to use memory it doesn’t have permission to use, the program fails and the computer and operating system appropriately handle the error and crash to protect the rest of the system.
In order to ensure that drivers are installed correctly we need a safe way to test them, what computer scientists call a sandbox, a place where you can try building something without fear of getting hurt or destroying a working system. I designed my sandbox by installing driver packages onto the operating system software before it is installed on a machine. The system then installs that same, altered, operating system software on a virtual machine (VM). A virtual machine is a simulated computer that runs a full operating system as a program on an existing operating system. The VMs gave me flexibility in terms of not taking an entire machine out of commission to test. If something goes wrong when I perform my test, I can scrap the VM and start again, similar to deleting a program on your computer that was running poorly and reinstalling it. I also can hand off a copy of the machine to a fellow team member to inspect. In addition to creating a safe way to test the installation process, virtual machines introduce scalability for the test teams. A single server can run multiple VMs at that same time and test different configurations. This in turn reduces the number of machines required to test numerous scenarios and allows for easy parallelization of the tests. There are also benefits to manageability and control that the system offer, but those are discussions for another day. The system is complex, but useful for testing various many OS problems, not just driver package installation. By the end of my twelve weeks, I was able to demo my prototype to my team. The system presented exciting possibilities, and team members started coming up with new scenarios that the system might be used to test in the future once it is fully functioning.
At the end of the summer I had a project I was proud of and that was useful to my team. I have since returned to MSU to finish my Master’s degree, but I am excited to say that I will be starting at Microsoft as a full time employee next summer.
For more information about Michelle’s work, you can contact her at vogelmi3 at msu dot edu.
