hide and lock windows taskbar after command this.WindowState = FormWindowState.Maximized;

You can use this code to hide, or show, the TaskBar:

// required
using System.Runtime.InteropServices;

// in Form or Class scope
[DllImport("user32.dll")]
private static extern IntPtr FindWindow(string className, string windowText);
[DllImport("user32.dll")]
private static extern bool ShowWindow(IntPtr hwnd, int command);

private const int SW_HIDE = 0;
private const int SW_SHOW = 1;

private bool IsTaskBarShown = true;

private IntPtr TaskBarHWnd = FindWindow("Shell_TrayWnd", "");

private void setTaskBarState(bool isShown)
{
    // can't find a TaskBar : game-over
    if (TaskBarHWnd == null) return;

    IsTaskBarShown = isShown;

    if (IsTaskBarShown)
    {
        ShowWindow(TaskBarHWnd, SW_SHOW);
    }
    else
    {
        ShowWindow(TaskBarHWnd, SW_HIDE);
    }
}

// reason for this is discussed below
private void Form1_FormClosing(object sender, FormClosingEventArgs e)
{
    if (! IsTaskBarShown) setTaskBarState(true);
}

1. If you hide the TaskBar, it's hidden "globally:" if the user switches to another application, there's no TaskBar. If you close your Application, with the TaskBar hidden, it will stay hidden.

Without knowing whether the TaskBar is shown or hidden when the Application starts, we might without meaning to change its state and leave that changed state in effect when the user closes our Application.

To make a "stab" at leaving the TaskBar hidden when the Application terminates, you can see that in the code example a FormClosing EventHandler was created that makes sure the TaskBar is visible when the Application terminates ... but, what if the TaskBar was hidden to begin with: clearly this is not a complete solution as is.

2. If you press the Windows Key, with the TaskBar hidden using this technique, the Start menu will pop-up, but no TaskBar.

So: a more "robust" solution would require determining the state of the TaskBar when the Application starts, and restoring that state ... if we had changed it ... on exit. The fun and glory of implementing that is left to the OP. You can get a smell of issues in determining what TaskBars are implemented, and whether they are visible, or not, here: [^].

Discussion:

In terms of design, it's generally not a good thing to lock-out the user from using Windows the way they have configured it; of course, there are exceptions like creating a kiosk-mode application for a dedicated something-or-other; or, creating special applications for things like internet rental facilities; or, other possible security-related purposes. Or, preventing a child from running amok hitting keys while using your whatever-for-children program.

In this case, we can/should ask why the user should not have access to the TaskBar, but still have access to the Windows Start Menu, and using alt-Tab to switch between Applications.