Protect Yourself From Tech Support Scams
July 29, 2020
Protect Yourself From Tech Support Scams
Tech support scams are an industry-wide issue where scammers trick you into paying for unnecessary
technical support services. You can help protect yourself from scammers by verifying that the contact is a
Microsoft Agent or
Microsoft Employee and that the phone number is an
Microsoft global customer service number.
Random BSOD showing "Caused By Driver : ntoskrnl.exe"
ok im working on a Dell Inspiron One (AIO) which was infected with a bunch of viruses, i've cleaned the system (malwarebytes Trendmicro housecall, norton antivirus) and all was cleaned up that they found, i also cleaned up a ton of temp files and other
things, this bsod has been happening before i started working on it.. it will be fine until something heavy starts, E.G virus scan, or MBAM scanner, even bsod when i was defragging it, the screen will turn to a static with white and blue nicks throughout
it. then it will BSOD reboot and work fine for a few hours. some times it will happen before windows even gets fully loaded.. i did a clean boot and it still happen. i've uploaded the application event log and system event log along with the 4 dump files
that was on the drive on to my skydrive @ https://skydrive.live.com/redir?resid=155A99050BC2AEE7!235&authkey=!AD-yMH4iYblvTRo if any one can be kind enought to look at these and tell me what is causing this i would be most gratefull here is a text of the
last dump file as viewed via BLUESCREENVIEW,
Every single one of them was caused by an access violation. What caused this access violation was the function -
Windows' security model requires that a thread specifies up front, at the time that it opens an object, what type of actions it wants to perform on the object. The object manager calls the SRM (Windows File System Agent) to perform access checks based
on a thread's desired access, and if the access is granted, a handle is assigned to the thread's process with which the thread (or other threads in the process) can perform further operations on the object. The object manager records the access permissions
granted for a handle in the process's handle table.
One event that causes the object manager to perform security access validation is when a process opens an existing object using a name. When an object is opened by name, the object manager performs a lookup of the specified object in the object manager namespace.
If the object isn't located in a secondary namespace, such as the configuration manager's registry namespace or a file system driver's file system, namespace, the object manager calls the internal function
ObpCreateHandle once it locates the object. As its name implies, ObpCreateHandle creates an entry in the process's handle table that becomes associated with the object.
ObpCreateHandle first calls ObpIncrementHandleCount to see if the thread has permission to access the object, and if the thread does,
ObpCreateHandle calls the executive function ExCreateHandle to create the entry in the process handle table. ObpIncrementHandleCount
calls ObCheckObjectAccess to carry out the security access check.
If we take a look at the call stack (which is the same throughout each dump):
We can see an NtCreateSection call which creates a section object which is an object that represents a section of memory that can be shared. We then see a
ObInsertObjectEx call which is reserved for system use. We then after see a
ObpCreateHandle as I explained above. From this, we can see that there was no
ObpIncrementHandleCount call to see if the thread had permission to access the object. With this said,
ExCreateHandle was never called to create the entry in the process handle table, and ultimately the security access check was never carried out.
What does all of this mean overall? Well, it can mean few things, but from a quick first glance and analysis, it appears that you are still possibly infected with some sort of malware. To be sure we aren't however dealing with any other device driver corruption
and or conflicts, let's go ahead and enable Driver Verifier:
What is Driver Verifier?
Driver Verifier is included in Windows 8, 7, Windows Server 2008 R2, Windows Vista, Windows Server 2008, Windows 2000, Windows XP, and Windows Server 2003 to promote stability and reliability; you can use this tool to troubleshoot driver issues. Windows kernel-mode
components can cause system corruption or system failures as a result of an improperly written driver, such as an earlier version of a Windows Driver Model (WDM) driver.
Essentially, if there's a 3rd party driver believed to be at issue, enabling Driver Verifier will help flush out the rogue driver if it detects a violation.
Before enabling Driver Verifier, it is recommended to create a System Restore Point:
Start > type "verifier" without the quotes > Select the following options -
1. Select - "Create custom settings (for code developers)"
2. Select - "Select individual settings from a full list"
3. Check the following boxes -
- Special Pool
- Pool Tracking
- Force IRQL Checking
- Deadlock Detection
- Security Checks (Windows 7 & 8)
- DDI compliance checking (Windows 8)
- Miscellaneous Checks
4. Select - "Select driver names from a list"
5. Click on the "Provider" tab. This will sort all of the drivers by the provider.
6. Check EVERY box that is [B]NOT[/B] provided by Microsoft / Microsoft Corporation.
7. Click on Finish.
Important information regarding Driver Verifier:
- If Driver Verifier finds a violation, the system will BSOD.
- After enabling Driver Verifier and restarting the system, depending on the culprit, if for example the driver is on start-up, you may not be able to get back into normal Windows because Driver Verifier will flag it, and as stated above, that will cause /
force a BSOD.
If this happens, do not panic, do the following:
- Boot into Safe Mode by repeatedly tapping the F8 key during boot-up.
- Once in Safe Mode - Start > type "system restore" without the quotes.
- Choose the restore point you created earlier.
If you did not set up a restore point, do not worry, you can still disable Driver Verifier to get back into normal Windows:
- Start > Search > type "cmd" without the quotes.
- To turn off Driver Verifier, type in cmd "verifier /reset" without the quotes.
・ Restart and boot into normal Windows.
How long should I keep Driver Verifier enabled for?
It varies, many experts and analysts have different recommendations. Personally, I recommend keeping it enabled for at least 24 hours. If you don't BSOD by then, disable Driver Verifier.
My system BSOD'd, where can I find the crash dumps?