TechOnTip Weblog

Run book for Technocrats

Archive for October, 2011

Windows failed to start. Error 0xc000000e. The boot selection failed because a required device is inaccessible

Posted by Brajesh Panda on October 19, 2011

Here is how the Windows screen looks in a failed environment.

Here is how boot manager & loaders looks in a good machine

Reboot the corrupted machine using respective OS media & select Repair Option & then open command prompt. From command prompt run bcdedit. Here it is how the corrupted things look like. It might have lost all the partition information’s.

To fix this let run “STARTREP.EXE” from X:\sources\recovery
directory. After this reboot the server. It will fix boot loader stuff & computer will come up correctly.

Here is another promising command “bootrec.exe”. http://support.microsoft.com/kb/927392

Posted in WindowsServer | Tagged: | 5 Comments »

Application Crash due to “Data Execution Prevention” – COM Surrogate

Posted by Brajesh Panda on October 18, 2011

Today one of the application administrator complained me that below error popped-up in the server & application crashed.

After doing little bit research found there is a setting called Data Execution Prevention (well I never used this thing). Switched it to the 1st Option that is “Turn on DEP for essential Windows Programs and services only” and application started working

Data Execution Prevention (DEP) is a set of hardware and software technologies that perform additional checks on memory to help prevent malicious code from running on a system. In Microsoft Windows XP, Windows 2003, DEP is enforced by hardware and by software.

The primary benefit of DEP is to help prevent code execution from data pages. Typically, code is not executed from the default heap and the stack. Hardware-enforced DEP detects code that is running from these locations and raises an exception when execution occurs. Software-enforced DEP can help prevent malicious code from taking advantage of exception-handling mechanisms in Windows.

Here is a nice MSDN article about DEP

Data Execution Prevention (DEP) is a system-level memory protection feature that is built into the operating system starting with Windows XP and Windows Server 2003. DEP enables the system to mark one or more pages of memory as non-executable. Marking memory regions as non-executable means that code cannot be run from that region of memory, which makes it harder for the exploitation of buffer overruns.

DEP prevents code from being run from data pages such as the default heap, stacks, and memory pools. If an application attempts to run code from a data page that is protected, a memory access violation exception occurs, and if the exception is not handled, the calling process is terminated.

DEP is not intended to be a comprehensive defense against all exploits; it is intended to be another tool that you can use to secure your application.

How Data Execution Prevention Works

If an application attempts to run code from a protected page, the application receives an exception with the status codeSTATUS_ACCESS_VIOLATION. If your application must run code from a memory page, it must allocate and set the proper virtual memory protection attributes. The allocated memory must be marked PAGE_EXECUTE, PAGE_EXECUTE_READ, PAGE_EXECUTE_READWRITE, orPAGE_EXECUTE_WRITECOPY when allocating memory. Heap allocations made by calling the malloc and HeapAlloc functions are non-executable.

Applications cannot run code from the default process heap or the stack.

DEP is configured at system boot according to the no-execute page protection policy setting in the boot configuration data. An application can get the current policy setting by calling the GetSystemDEPPolicy function. Depending on the policy setting, an application can change the DEP setting for the current process by calling the SetProcessDEPPolicy function.

Programming Considerations

An application can use the VirtualAlloc function to allocate executable memory with the appropriate memory protection options. It is suggested that an application set, at a minimum, the PAGE_EXECUTE memory protection option. After the executable code is generated, it is recommended that the application set memory protections to disallow write access to the allocated memory. Applications can disallow write access to allocated memory by using the VirtualProtect function. Disallowing write access ensures maximum protection for executable regions of process address space. You should attempt to create applications that use the smallest executable address space possible, which minimizes the amount of memory that is exposed to memory exploitation.

You should also attempt to control the layout of your application’s virtual memory and create executable regions. These executable regions should be located in a lower memory space than non-executable regions. By locating executable regions below non-executable regions, you can help prevent a buffer overflow from overflowing into the executable area of memory.

Application Compatibility

Some application functionality is incompatible with DEP. Applications that perform dynamic code generation (such as Just-In-Time code generation) and do not explicitly mark generated code with execute permission may have compatibility issues on computers that are using DEP. Applications written to the Active Template Library (ATL) version 7.1 and earlier can attempt to execute code on pages marked as non-executable, which triggers an NX fault and terminates the application; for more information, see SetProcessDEPPolicy. Most applications that perform actions incompatible with DEP must be updated to function properly.

A small number of executable files and libraries may contain executable code in the data section of an image file. In some cases, applications may place small segments of code (commonly referred to as thunks) in the data sections. However, DEP marks sections of the image file that is loaded in memory as non-executable unless the section has the executable attribute applied.

Therefore, executable code in data sections should be migrated to a code section, or the data section that contains the executable code should be explicitly marked as executable. The executable attribute, IMAGE_SCN_MEM_EXECUTE, should be added to the Characteristics field of the corresponding section header for sections that contain executable code. For more information about adding attributes to a section, see the documentation included with your linker.

Posted in WindowsServer | 1 Comment »

URL Monitoring using SCOM 2007 R2

Posted by Brajesh Panda on October 17, 2011

Some good articles over here -

http://www.scom2k7.com/

Method 1: http://www.scom2k7.com/bulk-url-editor/

Method 2: http://www.scom2k7.com/custom-url-management-pack-by-russ-slaten/

Method 3: http://www.scom2k7.com/web-application-management-pack-template/

Posted in Tools | Leave a Comment »

The Celerra Management Service is not responding for task Query Data Movers All

Posted by Brajesh Panda on October 6, 2011

Model: VNX 5300

Unisphere: V1.1.0.1.0387

Control Station: Linux release 3.0

Nas Version: 7.0.14-0

Symptom: While browsing File Hardware details like Data Movers, File Network Details etc using Unisphere it didn’t render details & show a warning like “The Celerra Management Service is not responding for task Query Data Movers All

Data Movers looks good from ssh

Ran Health Check & Seems everything is good.

# /nas/bin/nas_checkup

Checked HTTP Daemons in Control Station

Checked NAS Daemons in Control Station

Restarted HTTPD daemon thinking Unisphere might not able to pull in details about data movers

Now Management Service Error gone – New Java webserver error popped up

Again Stopped & Started HTTPD daemon & it comes back to old state

So what is this error? Let’s reboot the control station & see how it is going ;-)

SSH as Root & reboot

It comes back to good state

However is there a service/daemon which can be recycled to fix this issue without rebooting control station? I will update this thread when I will get to know that ;-)

Spoke to EMC support, support guy told me – APL daemon was crashing which provides information to unishpere GUI window. Recommended way to restart the control station just to refresh all daemons. Just to note there will be no production downtime due to CS reboot.

Posted in EMC Storage, VNX5300 | Tagged: , | Leave a Comment »

 
Follow

Get every new post delivered to your Inbox.

Join 54 other followers

%d bloggers like this: